ИИ не заменит QA-инженера: эксперимент на 2000 тестах и реальные выводы

Способен ли искусственный интеллект полностью заменить QA-инженера? Короткий ответ: нет, но он может стать мощным помощником в рутинных задачах. В этой статье мы разберём реальный эксперимент, в котором AI-ассистенту поручили анализ и исправление 2000 автотестов, и выясним, где ИИ действительно поле

Многие команды QA сталкиваются с проблемой: автотесты пишутся для экономии времени, но со временем их обслуживание начинает отнимать больше ресурсов, чем экономит сама автоматизация. Тест упал в CI — нужно открыть Allure, подключиться к стенду через VPN, авторизоваться, изучить DOM, найти сломавшийся локатор. На один такой тест уходит от получаса до часа. После каждого релиза фронтенд меняет вёрстку, и ещё несколько дней уходит на починку локаторов. А когда утром видишь 200 красных тестов при нетронутом коде, начинается настоящее расследование. В такие моменты хочется делегировать всю эту рутину AI-ассистенту и заняться действительно важными задачами. Команда SENSE так и сделала, но панацеи не получилось. ИИ снимает часть нагрузки и экономит часы, но на сложных кейсах он ошибается, ходит по кругу и с уверенным видом выдаёт несуществующие локаторы за настоящие.

Как мы дали ИИ 2000 тестов и что из этого вышло

Егор Лаптев, QA Fullstack Java в SENSE, на проекте крупного российского банка решил проверить, способен ли ИИ заменить QA-инженера. Для эксперимента команда отобрала 2000 реальных тестов: UI-тесты на Selenide и Cucumber, API-тесты на REST Assured, отчёты в Allure, интеграции через Kafka, инфраструктура на Moon в Kubernetes. Цель — оценить, как ИИ справляется с анализом упавших тестов, исправлением локаторов и генерацией новых проверок. Результаты оказались неоднозначными: ИИ показал себя хорошо на типовых задачах, но провалился на сложных сценариях, требующих глубокого понимания контекста.

Предыстория и контекст

Проблема обслуживания автотестов знакома каждой команде, которая использует Selenium или его аналоги. Когда тестов становится много, их поддержка превращается в тяжёлую ношу: фронтенд меняется, тесты падают из-за нестабильности окружения, а время на диагностику растёт. Идея привлечь ИИ для автоматизации этой рутины витает в воздухе уже несколько лет. С появлением больших языковых моделей (LLM) и инструментов вроде GitHub Copilot стало возможным делегировать часть задач AI-ассистенту. Однако на практике выяснилось, что ИИ — не волшебная таблетка. Он отлично справляется с шаблонными операциями, но теряется, когда нужно анализировать сложные логические цепочки или учитывать бизнес-контекст.

Как ИИ анализирует упавшие тесты?

Ассистент подключается к Allure, парсит лог ошибки и пытается определить причину падения. В простых случаях — например, когда изменился CSS-класс или текст кнопки — ИИ находит проблему за секунды и предлагает исправление. Но если тест упал из-за сложного стека вызовов, асинхронного поведения или нестабильности окружения, модель начинает «галлюцинировать»: она придумывает несуществующие локаторы, предлагает изменить логику теста или просто выдаёт абсурдные рекомендации. В одном из кейсов ИИ утверждал, что элемент существует, хотя на самом деле его не было в DOM.

Технические детали: как устроен AI-ассистент для QA

В основе ассистента — комбинация LLM (например, GPT-4 или отечественных аналогов) и набора инструментов для взаимодействия с инфраструктурой. Ассистент умеет читать логи Allure, выполнять запросы к Moon (платформа для запуска тестов в Kubernetes), анализировать DOM-дерево и даже запускать тесты повторно. Для каждого упавшего теста он формирует промпт, в который включает: название теста, шаги, скриншот (если есть), лог ошибки и контекст (например, версию сборки). Затем модель возвращает диагноз и, если возможно, исправленный код. Стоимость одного запроса к LLM — около 0,1–0,5 цента, в зависимости от модели. Для 2000 тестов это вылилось в несколько десятков долларов, что сопоставимо с зарплатой одного QA за час.

Какие типы ошибок ИИ исправляет хорошо, а какие — плохо?

Эксперимент показал, что ИИ отлично справляется с исправлением локаторов при изменении CSS-классов, текстовых меток или структуры DOM. Например, если кнопка сменила id с "submit-btn" на "submit-button", ассистент быстро находит актуальный локатор и обновляет тест. Однако с ошибками, связанными с асинхронностью (например, элемент не успел загрузиться), ИИ справляется хуже: он часто предлагает добавить ожидание, но не может корректно определить таймаут или условие. Самые сложные случаи — это падения из-за бизнес-логики: например, когда тест проверяет сумму на счете, а она не совпадает из-за изменения в API. Здесь ИИ бессилен, так как не понимает предметную область.

Кого затронет и как

Разработчики и QA-инженеры: для них ИИ становится помощником в рутинных задачах, но не заменой. Сложные кейсы всё равно требуют человеческого вмешательства. Бизнес: может рассчитывать на сокращение времени на поддержку тестов на 20–30%, но не на полную автоматизацию. Конкуренты: компании, которые внедрят ИИ-ассистентов раньше, получат преимущество в скорости релизов. В российском контексте важно учитывать, что использование западных LLM может быть затруднено, поэтому команда SENSE тестировала и отечественные модели — их качество пока ниже, но прогресс идёт быстро.

Что будет дальше

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

Итог

ИИ не заменит QA-инженера, но может стать мощным инструментом для сокращения рутины. Эксперимент на 2000 тестах показал: ассистент экономит часы на типовых задачах, но на сложных кейсах ошибается. Главный вывод — ИИ нужно внедрять постепенно, с чётким пониманием его ограничений, и не ждать чуда.