Кейс

Как сократили регресс на медицинском проекте

Внедрение автоматизированного тестирования (AQA) с ИИ-инструментами

Клиент

Разработчик ПО для аппаратов лучевой терапии

Технологии

Python, Playwright, PyTest, Chromium, Allure.

Тип работ:

Внедрение процессов автоматизированного тестирования

О проекте

Заказчик развивает российское программное обеспечение для планирования лучевой терапии. Система помогает медицинским специалистам создавать индивидуальные планы лечения, работает с данными диагностического и терапевтического оборудования, поддерживает в том числе сценарии брахитерапии.

Для такого продукта особенно важны стабильность релизов, предсказуемость изменений и качество проверок. Часть сценариев длинная, сквозная и включает расчёты, загрузки данных и последовательную работу в нескольких разделах системы.

Задача

Регрессионное тестирование занимало от недели до двух. В продукте много связанных сценариев. Чтобы проверить один из них, тестировщику требуется выполнить десятки предшествующих действий. Одновременно команда проверяет задачи текущего спринта, поэтому ручной регресс становился ограничением для скорости выпуска обновлений.

До старта работ автоматизирован был только небольшой набор smoke-проверок в Postman. Нужно было постепенно покрыть регресс автотестами, не передавая внешним ИИ-инструментам исходный код продукта и чувствительные данные.

Подход

Команда начала внедрение AQA с критичных и повторяемых сценариев.
Для UI-автоматизации использовали Python, Playwright и PyTest. Тесты запускаются в Chromium, построены по модели Page Object, результаты формируются в Allure.

ИИ применяли как инструмент, который помогает ускорить рутинную часть работы:

подготовить первые тесты для авторизации и smoke-сценариев;
генерировать и дорабатывать тестовый код по правилам проекта;
готовить скрипты и настройки для будущего CI/CD-пайплайна;
разбирать падения тестов и предлагать исправления;
создать дашборд для контроля покрытия и статуса автоматизации.

При этом QA-инженеры сохраняют полный контроль: определяют приоритетные сценарии, задают архитектурные правила, проверяют селекторы, валидируют код и принимают изменения перед мержем.

Безопасность

По требованиям заказчика во внешние ИИ-инструменты не передавались исходный код фронтенда и бэкенда, файлы существующих пайплайнов, секреты из переменных окружения и чувствительные данные, обрабатываемые в системе.

Тестировщик самостоятельно изучал интерфейс, подтверждал селекторы и передавал ИИ только необходимый технический контекст для подготовки тестов. Это позволило использовать ИИ как инструмент разработки без доступа к данным проекта.

Что построили вокруг автотестов

Помимо самих тестов, команда собрала два внутренних инструмента: сервис регресса и дашборд автоматизации.

Инструмент для регресс

Раньше регресс вёлся вручную в общей таблице: результаты и баги считали руками, сравнить прогоны между спринтами было нельзя, а баги и тест-кейсы из Azure DevOps приходилось сверять вручную. Когда счёт кейсов пошёл на тысячи, это стало отнимать много времени.

Инструмент заменил документ и сейчас используется для контроля ручного регресса. В нём есть:

Дерево кейсов с приоритетами. Разделы и подразделы, результат ставится в один клик: «пройден», «баг», «баг исправлен», «не тестируется».
Совместная работа в реальном времени. Несколько инженеров берут разделы в работу одновременно, изменения синхронизируются у всех сразу.
Баги из Azure DevOps. Подтягиваются автоматически по стенду и версии: id, серьёзность, состояние, ответственный; статус «исправлен» синхронизируется без ручных правок.
Сквозная трассировка. Каждый кейс регресса связан со своими тест-кейсами в Azure DevOps по id. Видно, что чем покрыто, прямо в интерфейсе.
Готовая сводка и отчёт. Прогон кейсов, баги по серьёзности, ручные поля для найденного на демо и на спринт-ревью, и экспорт того же самого в PDF одной кнопкой.

Дашборд автоматизации

Второй инструмент показывает насколько на самом деле продвинулась автоматизация. В нём есть:

Покрытие по разделам продукта. Разбивка по функциональным блокам показывает, какие разделы отстают и в первую очередь требуют автоматизации.
Динамика во времени. Прогресс автоматизации виден от спринта к спринту.
Разбор упавшего прогона на месте. Лог открывается прямо в дашборде: какая проверка не прошла, локатор, ответ сервера.
Трассировка тест-кейс → автотест. Связь тест-кейса в Azure DevOps с конкретными автотестами в коде.
История прогонов: статус, запуск и итог.

Оба инструмента созданы с возможностью доработок. С небольшими доработками их можно перенести и на другую систему трекинга задач.

Результаты первого этапа

Команда автоматизировала smoke-сценарии одного из модулей брахитерапии и часть проверок административного интерфейса.

Сквозной smoke-сценарий, который вручную занимал около 10 минут, теперь выполняется менее чем за 2 минуты.
Проверка административного интерфейса, занимавшая у тестировщика 2–3 часа, выполняется автотестами менее чем за 10 минут.
Во время подготовки тестов удалось обнаружить несколько UI-дефектов и передать их на исправление.
На первом этапе команда автоматизировала 110 приоритетных тест-кейсов и создала дашборд, который помогает контролировать покрытие и выбирать следующие сценарии для автоматизации.

Что дальше

Сейчас команда настраивает запуск автотестов в CI/CD-пайплайне. Затем планирует расширять покрытие регресса и подключать автоматизированную проверку новых задач в течение спринта.

ИИ в этом подходе не заменяет QA-инженера. Он помогает быстрее начать автоматизацию и снять с команды часть рутины, а эксперты концентрируются на выборе критичных сценариев, бизнес-логике и контроле качества тестов.

Хотите ускорить разработку на вашем проекте?

Заполните форму, и мы с вами свяжемся