ИИ в тестировании: где он действительно помогает, а где только мешает – опыт Test IT

Искусственный интеллект все чаще становится частью повседневной работы по контролю за качеством: от нагрузочного тестирования до разработки через спецификацию и работы с системой управления тестами. Но у этого подхода две стороны: ИИ способен ускорить команду в разы, а может и навредить. Например, подогнать тесты под «зеленый» результат или удалить данные из боевой базы. Разберемся, для каких задач ИИ в тестировании приносит реальную пользу (в том числе внутри Test IT), а где его применять не стоит.

В новом выпуске разговора «Без Багов» инженеры платформы Test IT из разных направлений поделились своей практикой работы с инструментом. Рассказали, где ИИ уже встроен в их ежедневные процессы по нагрузочному тестированию, автоматизации и разработке, и где сознательно не используется. В статье мы собрали главное. Все выводы подкреплены практикой команды Test IT и тем, как ИИ применяется в работе с собственной платформой управления тестированием.

Что ИИ умеет хорошо в тестировании

1. Снимать рутину и собирать контекст

Это самая первичная и очевидная зона применения. ИИ берет на себя монотонную работу и освобождает инженеру время для смысловых задач.

Хороший пример – разбор падений автотестов. Обычно это утомительный процесс: открыть тест, посмотреть стек ошибки, сходить в Git, проверить вложения в TMS, найти похожие падения в истории. 

Команда автоматизации Test IT собрала внутренний сервис, который сначала собирает весь контекст, а затем подключает модель за гипотезами. Результат — сокращение первичного анализа в 10–15 раз: вместо 10–15 минут ручного разбора каждого падения инженер открывает готовый тред с гипотезами и следующими шагами.

«ИИ снимает рутину – а финальное решение все равно остается за человеком», — Андрей Черных, руководитель группы автоматизации тестирования в Test IT.

Та же логика, как рассказывает эксперт, действует и в нагрузочном тестировании. В работе Андрея ИИ не выполняет работу вместо инженера. Инструмент просто убирает все, что мешает этой работой заниматься.

2. Собирать собственные инструменты и дорабатывать чужие

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

Наш инженер по нагрузочному тестированию не пишет на Java, но это не помешало ему доработать чужой плагин с GitHub под свои задачи (складывать результаты тестов в нужную базу). Разобраться в массивном пайплайне GitLab, на что раньше уходили дни, теперь можно потратив не более полутора часов. Эти компетенции мы перенесли  в развитие своей платформы.

3. Работать там, где важен смысл, а не точная цифра

ИИ хорошо справляется со смысловыми задачами: трактовать результаты, искать корреляции, формировать гипотезы. Главное – правильно разделять зоны ответственности.

«Где вход стабильный и формализованный – там лучше использовать код. Где вход плавающий и смысловой – там место модели», – Пётр Иванов, инженер по нагрузочному тестированию Test IT.

4. Помогать в работе с тест-артефактами внутри платформы

Это применение особенно близко нам как разработчикам платформы управления тестированием. ИИ пишет черновики тест-кейсов, позволяет работать быстрее с тестовой документацией, генерировать автотесты, а через MCP можно подключить ИИ-ассистента, чтобы работать с контекстом напрямую из Test IT. Кейсы тянутся из системы, документация по продукту хранится в векторной базе для контекста. Парсер держит локальные копии в актуальном состоянии. Все это позволяет быстро и массово редактировать кейсы.

Test IT позволяет централизованно управлять тест-кейсами, автоматизировать проверки и анализировать результаты в едином пространстве – а описанные сценарии работы с ИИ органично встраиваются в этот процесс.

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

Где ИИ применять не стоит: 5 типичных ошибок

В историях с ИИ не может быть только плюсов. Рассказываем пять ситуаций, в которых ИИ в тестировании скорее навредит – и которые мы разобрали на собственной практике.

Ошибка 1. Отдавать модели точные расчеты и метрики

На большом количестве временных точек модель начинает «плыть», а одна галлюцинация в цифре обесценивает весь анализ. Точную математику: сравнение прогонов, пороги, подсветку деградаций – лучше считать детерминированным кодом.

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

Без подготовленного контекста это дает шум, галлюцинации и плохую воспроизводимость. Правильный порядок: сначала факты и контекст, затем базовая классификация кодом, и только потом – модель за интерпретацией.

Ошибка 3. Делегировать нейросети вообще все

Если и спецификацию, и код генерирует модель, то при появлении бага становится непонятно, что считать правдой – ошибку в спецификации или в коде. Это приводит к «дедлоку агентов».

Ошибка 4. Доверять «зеленому» тесту и забывать про безопасность

Агент склонен подгонять тесты под успешный результат – например, использовать урезанные данные в теле запроса, которые не отражают реальное поведение продукта. А без явного указания требований безопасности модель попросту их игнорирует.

«Скрипт выглядит солидно и зеленеет – но это еще не доказывает, что верно выбраны модель, данные и критерии», — Пётр Иванов.

Кстати, чем выше скорость разработки с ИИ, тем сильнее растет churn кода (это количество постоянно переписываемых участков). И есть оценки, где показатель доходит до 147%.

Ошибка 5. Давать агенту широкие права без точек отката

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

Когда что использовать: выводы

• ИИ – для рутины и смысловых задач: сбор контекста по падениям, черновики тест-кейсов и тест-планов, доработка инструментов, формирование гипотез.

ИИ делает дешевле именно создание артефактов: самих кейсов, автотестов, отчетов.  но не их приемку и не ответственность за результат.

• Детерминированный код –  для точности: расчеты, метрики, базовая классификация, формальные контракты (например, OpenAPI).

Применяйте ИИ там, где вход смысловой и важна скорость на рутине; оставляйте коду точные расчеты и базовые решения.

• Человек как фактор финального решения: приемка, оценка рисков и ответственность за релиз остаются за инженером. Именно это отличает качество от количества сгенерированных артефактов.

Не делегируйте модели весь процесс целиком и не давайте агентам широкие права без точек отката. 

Эти выводы – часть большого разговора с командой Test IT на встрече разговор «Без Багов». Увидеть полные доклады с деталями, схемами и живой дискуссией – можно в записи встречи. 

А все описанные сценарии работы с тест-артефактами, прогонами и анализом результатов вы можете выстроить в единой среде с помощью нашей платформы Test IT. Бесплатный пробный период – доступен здесь.