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

Архитектура ИИ-ассистента построена по модели Supervisor-Worker с системой Skills, что позволяет распределять задачи между компонентами. Supervisor выступает в роли оркестратора, который анализирует контекст, определяет тип задачи и делегирует её выполнение конкретному воркеру. Workers, в свою очередь, имеют доступ к файловой системе, терминалу, Allure-отчётам, Bitbucket, Confluence, Jira и TestOps, что даёт им возможность выполнять широкий спектр операций. Skills представляют собой набор инструкций, которые определяют протоколы выполнения задач, адаптированные под конкретный проект. Ключевым ограничением системы является то, что Workers не видят историю чата, поэтому Supervisor обязан передавать весь контекст в каждом вызове. Если какая-то деталь пропущена, воркер работает вслепую, что приводит к ошибкам. Кроме того, Supervisor должен обязательно включать содержимое релевантных Skills в каждый вызов воркеру, иначе тот не сможет корректно выполнить задачу. Эта архитектура, хотя и кажется продуманной, на практике сталкивается с проблемами при обработке сложных сценариев, где требуется глубокое понимание контекста.

Практические сценарии использования ИИ-ассистента показали, что он может эффективно справляться с починкой упавших UI-тестов. Когда тест падает с исключением NoSuchElementException, ИИ определяет тип ошибки по стектрейсу, находит локатор в Page Object по аннотации @ElementName, проверяет реальный DOM через playwright-cli, сравнивает ожидаемый и реальный DOM, исправляет локатор, запускает тест и проверяет результат. Например, в коде Page Object с аннотациями, такими как @PageName("Карточка организации"), ИИ может быстро найти и исправить сломанный локатор. Однако на сложных кейсах, таких как отладка iframe и перекрытых элементов, ассистент демонстрирует ограничения. Элемент может быть виден в DOM, но Selenide его не находит из-за iframe, перекрытия, незагрузки или отсутствия прав. Каждая гипотеза требует 15–20 минут проверки на стенде, и ИИ часто ходит по кругу, выдавая несуществующие локаторы за настоящие. Это приводит к тому, что на сложных сценариях ассистент создаёт больше проблем, чем решает, требуя вмешательства человека.

Контекст эксперимента важен для понимания его результатов. В компании SENSE, где работает Егор Лаптев, проект крупного российского банка требует высокой надёжности тестов, так как ошибки могут привести к серьёзным последствиям. До внедрения ИИ команда тратила значительное время на рутинные задачи: упавший тест — это 30–60 минут рутины, релиз — несколько дней актуализации, массовые падения — 20–30 минут на диагноз, написание нового теста — 2–3 часа, отладка iframe — 1–2 часа. ИИ-ассистент был призван снять эту нагрузку, но на практике он справляется только с простыми задачами, такими как починка локаторов после изменений фронтенда. На рынке существует множество альтернатив, включая коммерческие решения от крупных вендоров, но большинство из них также сталкиваются с аналогичными проблемами при работе со сложными UI-флоу. Исследования в области ИИ в тестировании показывают, что генеративные модели часто ошибаются в контекстно-зависимых задачах, что подтверждает результаты эксперимента.

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

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