ГК Softline о том, как приручить ИИ для анализа падения тестов

Автоматизация тестирования создавалась ради одной цели — избавить инженеров от рутины, но сама стала источником новой.

Разбор падений сквозных тестов в постоянно развивающемся продукте превращается в бесконечный танец между системой тестирования, Git, Grafana и десятком других инструментов.

Часы уходят впустую, когнитивная нагрузка зашкаливает, релизы задерживаются. Андрей Черных из Test IT (входит в ГК Softline) рассказывает, почему нейросети бесполезны без жесткой архитектуры, как заставить ИИ работать предсказуемо и почему 20% ошибок — это норма.

Мы в Test IT (входит в экосистему Softline через «Девелонику» fabricaONE.AI) решили, что пора подключать большие языковые модели. Но быстро уткнулись в стену, так как просто скормить нейросети логи и ждать чуда — верный путь к галлюцинациям. Чтобы ИИ действительно помогал, понадобилась жесткая архитектура с детерминированными шагами, строгой валидацией и агрегацией контекста из множества источников. Ниже разбор того, что не сработало, как мы собрали рабочий конвейер и почему последнее слово все равно остается за человеком.

Масштаб: тысяча тестов и один дежурный

В нашем продукте уже перевалило за тысячу E2E-тестов, и счетчик не останавливается. Тесты написаны качественно: устойчивые локаторы, подготовка данных через API, все как положено. Но стоит случиться серьезному рефакторингу или выезжает новая функциональность, как начинается волна падений.

Разбор каждого случая требует контекста минимум из четырех-пяти источников. Инженер открывает Test IT, изучает шаги воспроизведения и вложения, затем идет в Git смотреть последние коммиты, потом в Grafana — проверять логи микросервисов. На одно падение уходят десятки минут, а на сто падений — весь день. Для компании с портфелем уровня Softline такая рутина — непозволительная роскошь. Нам нужен был инструмент, который снимет с человека роль постоянного сборщика пазла.

Что не работает: три иллюзии

Когда мы начали примерять большие языковые модели, быстро выяснилось, что три очевидных подхода тупиковые.

Первая иллюзия — правила редукции и регулярные выражения. Мы брали тексты ошибок и пытались их классифицировать. Подход дает лишь поверхностный анализ и полностью упускает контекст. Если упал простой ассерт с понятным текстом — все прозрачно. Но при проблемах с инфраструктурой регулярки оказываются абсолютно бессильны.

Вторая иллюзия — вера в силу простого промпта. Модель непредсказуема и при нехватке контекста начинает додумывать. А если вывалить на нее все подряд — теряет фокус и выдает рекомендации, оторванные от реальности. Золотая середина оказывается тоньше, чем хотелось бы.

Третья иллюзия — интеграция только с одним источником данных. Попытка завязать ИИ исключительно на Test IT не дала результата. Тестировщик при реальном разборе всегда смотрит в несколько систем одновременно. Эксперты ГК Softline отмечают, что модель полезна только тогда, когда контекст уже собран и проверен, а ИИ работает поверх готовой картины.

Архитектура: детерминизм побеждает

Мы выстроили процесс, в котором ИИ перестает быть черным ящиком и становится одним из инструментов конвейера. Для инфраструктуры уровня Softline хорошо работает поход, при котором нейросеть встраивается в процесс, а не заменяет его.

Сначала — исключительно детерминированные шаги. Сервис запускается на двух прогонах: эталонном и анализируемом. Эталонный прогон показывает, как система вела себя до изменений. На этом этапе мы собираем все данные и вложения по падению без какого-либо участия нейросети. Ноль выдумок на этапе сбора.

Затем — точечные вызовы ИИ. Скриншот уходит в Vision-модель, чтобы получить описание того, что происходит на экране. Логи из Test IT идут на поиск стектрейсов и ошибок. Шаги теста сжимаются в краткое резюме пользовательских действий. Все ответы и запросы мы упаковываем в JSON со строгой схемой и валидацией. Если модель возвращает некорректный формат, то результат отбрасывается, запрос повторяется.

Собранные сводки складываются в один большой JSON, по которому модель проводит финальный анализ первопричин. Затем — обязательная детерминированная калибровка. Абсурдные рекомендации вроде «удалить продукт» или «очистить базу данных» отсекаются на корню, анализируются противоречия, калибруется уровень уверенности. Итоговый отчет улетает в Slack, а в Test IT прикрепляется Markdown-файл с полным разбором, ссылками на задачи и логи в Grafana. Инженер получает полную картину — даже если модель где-то ошиблась, вся фактура перед глазами.

Большие языковые модели — вероятностные машины. Наша задача — загнать их в рамки CI/CD. В технологических командах Softline к промпам относимся к ним как к коду: версионируем, храним в репозитории, проходим обязательное ревью.

Главный инструмент контроля — evaluation-кейсы. Вот пример: написаны синтетические тесты с предсказуемым падением, например, с ассертом «42 ≠ 43». Ожидаем, что сервис вернет высокую уверенность в продуктовом падении, привязываясь не к конкретным числам, а к допустимым диапазонам. Это позволяет проверять изменения в промптах без работы с живыми данными. Обновил промпт — модель вылетела за рамки — сразу видна регрессия — откатываем. Плюс жесткие фильтры на уровне кода, которые не пропускают неприменимые рекомендации — практика, отработанная в том числе в проектах Softline.

Суровая реальность: скрытый контекст и 20% ошибок

Будем честны: волшебной таблетки не существует. Показатель уверенности модели сильно колеблется, и причина кроется в скрытом контексте. У ИИ нет того, что сидит в головах у людей, в документации и на макетах. В проектах Softline мы сталкиваемся с этим постоянно. Нейросеть не знает, что на вчерашней летучке договорились поменять API. Не видела скрытых требований в базе. Не слышала, как бэкендер предупреждал о специфическом поведении эндпоинта, которое тесты должны игнорировать. Этот контекст не оцифрован и недоступен алгоритмам.

Результат? Примерно в 20% случаев анализ первопричин получается некорректным. Модель может верно определить место падения, но абсолютно промахнуться с рекомендациями. В экосистеме Softline к этому давно привыкли и научились работать не с идеальным ИИ, а с тем, какой он есть. Это данность, с которой приходится жить.

Чтобы снизить процент ошибок, нужна база исторических классифицированных падений. В Test IT планируем дать модели возможность обучаться на прошлых кейсах — так прогнозы станут точнее. Это непрерывный процесс, и работы по сбору релевантного контекста не прекратятся никогда. Опыт проектов Softline показывает, что контекст — это бесконечный ресурс, который приходится постоянно оцифровывать.

Главный вывод: ИИ — инструмент, а не замена

Искусственный интеллект не может принимать финальные решения. Ему недоступен глубокий бизнес-контекст. В любом CI/CD-процессе модель должна сокращать путь к решению, но последнее слово остается за инженером. Это освобождает время для настоящих архитектурных задач, а не для бесконечного ковыряния в логах.

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

Сбор контекста, его жесткая валидация и детерминированная постобработка — три кита, на которых держится рабочее ИИ-решение в корпоративных системах. Забудьте о магических промптах. В реальном окружении работают только схемы, JSON и жесткий контроль. Для команды Softline и ее технологических активов это стало очевидно после месяцев экспериментов. И даже если рутина побеждена не до конца, теперь она занимает минуты, а не часы. Это и есть настоящая автоматизация, которая работает в проде.