QA-инженер прогнал 6500 E2E-тестов через ИИ-агента в OpenCode: что вышло

⚡ Главное за 5 секунд

• Ручной QA из TravelLine подключил ИИ-агента в OpenCode и провёл аудит примерно 6500 E2E-тестов перед переездом с Java на.NET.
• Агент читал локальные репозитории продукта и автотестов, а данные из TestIT тянул через MCP-сервер; модель — GPT-5.5.
• Условие входа жёсткое: без полного контекста и вылизанной инструкции агент путает suites и секции и отдаёт неполный список тестов.

🔍 Что случилось

Тестировщик TravelLine Ильсур Мингазов опубликовал на Хабре кейс: команда с продуктовой историей больше 15 лет накопила около 6500 E2E-тестов. Триггером аудита стал запланированный переезд автотестов с Java на.NET. Просто переписать всё «как есть» — значит утащить на новый стек и накопленный техдолг. Поэтому перед миграцией тесты разложили по четырём корзинам: мигрировать, переписать, спустить на уровень integration/API, удалить как дубль.

Механика такая. Репозиторий продукта и проект автотестов склонировали локально, OpenCode сам ходил по папкам и сопоставлял вызовы методов с классами. К TestIT сначала пробовали прямые запросы к API, потом перевели всё на MCP-сервер — агент дёргал готовые инструменты, а сервер под капотом ходил в API. Лёгкие Flash-модели отвалились на сопоставлении архитектуры, выбор пал на GPT-5.5: она держала длинный системный промпт с правилами тестовой пирамиды и строгий формат markdown-отчёта. Первая же секция вскрыла проблему: агент ориентировался на suites, а не на секции, и вернул неполный список. Пришлось отправить ему скриншот дерева, объяснить деление на секции-подсекции и закрепить порядок работы в инструкциях.

🧠 Наш разбор

Любопытно, кто в этой истории главный. Не модель и не MCP, а ручной QA, который вдруг стал постановщиком контекста для агента. Наша оценка: аудит тестов — это как раз тот класс задач, где ИИ не пишет код, а читает чужой и раскладывает по полочкам. Копипастить методы в чат бессмысленно, поэтому понадобились локальные репозитории и MCP. Именно связка «доступ к исходникам + доступ к TMS через нормальный протокол» превращает чат-бота в аудитора.

Что это меняет на практике. Обычно миграция стека — это переписывание вслепую: переносишь всё, потому что разбирать 6500 сценариев руками никто не даст денег и времени. Здесь появилась третья опция — сначала дешёвый разбор, потом перенос. Для кошелька это значит сдвиг затрат: меньше человеко-часов на чтение, больше на настройку агента и проверку его выводов. По опыту, второй пункт никто не считает, а он и съедает выгоду.

Кто выигрывает — команды с живым API у своей TMS и с репозиториями, которые можно склонировать. Кто проигрывает — те, у кого тесты живут в таблицах и вики, а также сторонники подхода «скормил список названий сценариев и жду чуда». Мы считаем, что статья ценна не моделью, а честным рассказом про отладку агента: половина текста — как он ошибался и как его поправляли.

⚠️ Чего мы не знаем

В тексте нет ни одной цифры эффекта: сколько тестов реально уехало в корзину «удалить», сколько часов сэкономили, сколько стоили токены и подписка. Объёмы тестовой базы автор округлил, внутренние сущности обезличил, а название модели GPT-5.5 мы берём как есть из статьи и не проверяли отдельно. Слабое место — «одна команда, один кейс»: воспроизводимость зависит от того, насколько похожи ваши TestIT-секции и структура репозитория.

Прогноз: в течение квартала появится ещё несколько публичных кейсов, где MCP-сервер к TMS (TestIT, Allure, Zephyr) — часть штатного пайплайна аудита. Если не появится, значит барьер не в моделях, а в настройке контекста.

Дисклеймер: один источник — кейс одной команды, автор округлил объёмы и обезличил внутренние сущности. Официально не подтверждено.

Источник: Хабр