Кейс: QA-агент разобрал 2 600 автотестов перед миграцией стека за две недели

Что произошло

27 октября на Хабре тестировщик TravelLine Ильсур Мингазов описал аудит автотестов с ИИ-агентом. Контекст: за 15 лет у продукта накопилось около 6 500 E2E-тестов на Java, а перед переносом на .NET команда решила не тащить весь накопленный долг в новый стек. Агента собрали в OpenCode: локальные копии репозиториев продукта и тестов, доступ к TMS TestIT через MCP-сервер, модель GPT-5.5 (лёгкие Flash-версии отсеяли на пробах — теряли детали), системный промпт с правилами тестовой пирамиды и жёсткий контракт ответа: каждый тест получает статус MIGRATE_TO_NET, SHIFT_TO_INTEGRATION или OBSOLETE_OR_BROKEN.

Первая же проверка поймала самого агента: он возвращал неполный список, потому что читал наборы (suites) вместо секций; правильный порядок закрепили в его инструкциях. На разборе секции Transfers агент сопоставил 18 E2E-тестов с интеграционными и нашёл 15 дублей — перенос «как есть» унёс бы их в новый стек. Вторая итерация добавила статистику прогонов из TestIT, до 100 последних запусков на тест: по каждой секции считались доля падений и P85 длительности успешных прогонов. В секции reports из 245 тестов (24 051 запуск, fail rate 6,6%) приоритет получили 9 тестов, которые одновременно часто падали и долго выполнялись.

За две недели команда провела смысловой аудит примерно 2 600 тестов и собрала статистику по всей базе: убраны дубли и около 450 неактуальных скриншотных тестов, заведены задачи на интеграционные тесты и на перенос проверенных сценариев. Настроенный агент остался в команде как постоянный инструмент с доступом к тестовой базе.

Почему это важно

Рутина этапа тестов — понять, что тест проверяет и зачем он нужен, — обычно не доходит до рук именно потому, что требует чтения кода и сопоставления с TMS. Здесь эту часть отдали агенту, а человеку оставили критерии, проверку выводов и спорные решения; миграция начинается с очищенной базы, а не с переписывания мусора в новый стек. Полезен и контракт из трёх статусов: агент отвечает следующим действием, а не «тест выглядит корректным». Ограничения: кейс одной команды, объёмы округлены и обезличены, все цифры приводит сам автор, независимой проверки нет.

Что с этим делать

• Перед крупной миграцией тестов прогоните аудит агентом: сопоставление тестов с кодом и TMS — его сильная задача, человек ставит критерии и спорит.
• Добавьте к аудиту статистику прогонов (fail rate и P85 по секциям): по коду не видно, какой тест флакает и тормозит конвейер.
• Формализуйте контракт ответа: статусы с конкретным следующим шагом вместо свободных заключений.