ИИ-агент на GPT-5.5 разобрал 2600 автотестов TravelLine за две недели

Тестировщик TravelLine Ильсур Мингазов за две недели провёл с ИИ-агентом аудит автотестов платформы для отелей. Смысловой разбор прошли примерно 2600 тестов из базы в 6500 E2E-сценариев, а статистику запусков собрали по всей базе. Поводом стал запланированный переезд тестов с Java на .NET. Команда решила, что перенос «как есть» утащит в новый стек и накопленный за 15 лет технический долг. В итоге в секции скриншотного тестирования удалили около 450 неактуальных тестов, а по ряду секций завели задачи на integration-тесты.

Окружение для агента: код, MCP и выбор модели

Списка названий сценариев из TMS для такой работы мало, поэтому агенту собрали полный контекст. Рабочее окружение выглядело так:

• OpenCode — среда, в которой работает агент.
• Локальные репозитории — клоны продукта и проекта с автотестами. Агент сам обходит папки, ищет методы и классы и сопоставляет вызовы, ничего не копируя в контекст вручную.
• TestIT через MCP — сначала пробовали прямые запросы к API, потом перешли на MCP-сервер. Агент вызывает готовые инструменты, а сервер забирает сущности, метаданные и прогоны.
• GPT-5.5 — из каталога OpenCode выбрали её. Лёгкие Flash-версии отбросили сразу: на сопоставлении архитектуры и сложной логики они теряли детали. GPT-5.5 удерживала длинный промпт с правилами тестовой пирамиды, точно вызывала MCP-тулы и не выдумывала связи между тестами и кодом.
• Системный промпт и контракт ответа — критерии деления на E2E и integration плюс строгий markdown-формат отчёта без «воды».

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

Первая итерация: перенести, спустить вниз или не трогать

В skill.md каждому тесту нужно было присвоить одну из трёх меток:

• MIGRATE_TO_NET — актуальный сценарий, переносится в .NET-фреймворк один в один;
• SHIFT_TO_INTEGRATION — бизнес-логика или API, которые стоит отдать бэкендерам для integration-тестов;
• OBSOLETE_OR_BROKEN — функционал удалён или изменён, тест сломан, дублирует другой или избыточен как UI-проверка; не переносится.

К E2E агент относил критичный happy path, сквозные пользовательские пути, связки подсистем, навигацию и отображение. К integration — расчёты, валидацию комбинаций данных, сохранение настроек и лимиты, то есть всё, где браузер только замедляет прогон.

Наглядный пример — секция Transfers. Из 18 E2E-тестов агент сопоставил сценарии с существующими integration-тестами и нашёл, что 15 из них дублируют проверки нижнего уровня, но делают это дороже и с большим риском нестабильных падений. Итог: 3 теста в MIGRATE_TO_NET, 0 в SHIFT_TO_INTEGRATION, 15 в OBSOLETE_OR_BROKEN. Прямой перенос принёс бы 15 лишних сценариев на .NET: больше времени прогона, больше падений для разбора и больше кода для поддержки.

Вторая итерация: P85 по падениям и длительности

Код не показывает, как часто тест падает и сколько идёт в реальности. Поэтому для каждого из ~6500 тестов запросили из TestIT до 100 последних результатов и сгруппировали их по секциям. Считали два показателя:

• fail rate — доля результатов Failed от общего числа, например 10 из 100 даёт 10%;
• P85 длительности — по запускам со статусом Passed; упавшие не учитывали, чтобы таймауты не искажали картину.

Внутри секции считали пороги P85 по обоим показателям и получили четыре группы: только частые падения, только долгие, пересечение и остальные. Пересечение разбирали первым. При этом долгий тест не всегда плох, а частые падения могут объясняться продуктом или окружением. Статистика формировала очередь на разбор, а не выносила приговор.

В секции reports агент насчитал 245 тестов, 24 051 запуск и 1598 падений, то есть fail rate 6,6%. Только по падениям в проблемную зону попали 29 тестов, только по длительности — 28, по обоим критериям — 9. Для этих девяти агент подготовил отчёт в DOCX и Markdown (passed / failed / P85 passed в секундах):

• изменение параметров заказа — 87 / 11 / 131,0;
• отмена операции с частичным перерасчётом — 86 / 11 / 102,0;
• фильтрация данных по параметрам — 88 / 10 / 308,0;
• проверка таймзоны в отчётах — 78 / 10 / 170,9;
• проверка периодичности в выгрузках — 75 / 11 / 162,0;
• подтверждение статуса сущности — 74 / 11 / 144,1;
• финализация оформления заказа — 75 / 9 / 169,8;
• отправка транзакционных уведомлений — 70 / 19 / 240,1;
• обработка платежа и проведение возврата — 63 / 33 / 253,7.

Что можно перенять другим командам

Роль человека в процессе осталась прежней: задавать критерии, проверять выводы агента и спорить о сложных случаях с разработчиками. Агент взял на себя поиск файлов, чтение кода, сопоставление проверок и сбор статистики. Результатом стал не отчёт, а набор задач. Убрали дубли, удалили около 450 скриншотных тестов, завели задачи на integration-тесты и на перенос проверенных сценариев, остальные секции поставили в очередь на обсуждение.

Для команд с большой тестовой базой урок практичный. Агенту нужен доступ к коду и системе управления тестами через MCP, а не выгрузка названий. Метки решений дают больше пользы, чем описания, а первичную проверку агента стоит заложить в план. Тесты, которые одновременно долгие и нестабильные, разумно разбирать первыми. Настроенный агент с правилами анализа остаётся в команде и может разбирать падения, искать существующее покрытие и оценивать новые сценарии без повторной сборки контекста.