Автоматизация тестирования десятилетиями продавалась бизнесу как панацея и способ сэкономить, но на практике превратилась в бездонную долговую яму. В большинстве крупных проектов стоимость владения инфраструктурой автотестов (TCO) вплотную приближается к выгоде от их наличия, а иногда и вовсе её перекрывает. Как отмечает Егор Лаптев, QA Fullstack Java в SENSE на проекте крупного банка, ситуация часто доходит до абсурда: на обслуживание тестов уходит больше ресурсов, чем на саму проверку продукта. Стоит фронтенд-команде обновить вёрстку, как инженеры на дни выпадают из реальности, актуализируя локаторы, а каждое «красное» утро в CI-системе оборачивается многочасовым расследованием причин падения.
Желание делегировать эту рутину нейросети выглядит логичным, но магии не случилось. Кейс SENSE, где ИИ «скормили» более 2000 тестов на стеке Selenide, Cucumber и REST Assured, выявил фундаментальную проблему: текущие модели — это не замена инженеру, а лишь инструмент сокращения времени на поиск ошибок, требующий неусыпного надзора. По сути, мы видим попытку переложить операционные расходы из одной статьи в другую, не меняя итоговой суммы в чеке.
Механика когнитивных галлюцинаций в DOM
Главный затык LLM-решений в QA — их неспособность работать с контекстом без костылей в виде алгоритмов-супервайзеров. В архитектуре Supervisor-Worker оркестратор обязан в каждом запросе передавать воркерам содержимое релевантных Skills — специфических протоколов проекта. Если эта инъекция данных сбоит, модель начинает галлюцинировать: она с обезоруживающей уверенностью выдает несуществующие локаторы за реальные.
ИИ снимает часть рутины и экономит часы, но на сложных кейсах он ошибается, ходит по кругу и с уверенным видом выдаёт несуществующие локаторы за настоящие.
В итоге бизнес получает новый вид скрытых потерь. Вместо того чтобы полчаса копаться в Allure-отчетах и DOM-дереве вручную, инженер тратит то же время на проверку того, не выдумал ли ассистент альтернативную физику для починки теста. С простыми NoSuchElementException ИИ справляется: находит локатор в Page Object через аннотации, сверяет его с DOM и вносит правки. Но как только в дело вступают iframe или перекрытые элементы, где Selenide «слепнет» по неочевидным причинам, ИИ начинает циклиться. Он раз за разом применяет стандартные паттерны там, где требуется инженерная интуиция, а не статистическая вероятность.
Экономика на грани фола
Для менеджмента внедрение такого ассистента — это жесткий расчет точки безубыточности. Написание одного сценария занимает 2–3 часа, а актуализация 15 элементов после смены вёрстки съедает до 4 часов работы специалиста. ИИ обещает срезать эти косты, но взамен требует развертывания тяжелой инфраструктуры — от Moon в Kubernetes до сложной настройки цепочек агентов.
Если отбросить маркетинговую шелуху, мы имеем дело с инструментом, который лишь «лечит» симптомы плохой архитектуры. Когда утренний прогон выдает 200 упавших тестов при нетронутом коде из-за проблем с инфраструктурой или «протухших» данных, ИИ может поставить диагноз за 20 минут вместо 30. Однако компания всё равно продолжает платить за непроизводительный труд: сначала за создание тестов, потом за их поддержку, а теперь ещё и за содержание ИИ, который поддерживает эти тесты.
Стратегический риск здесь — в «автоматизации ради автоматизации». Компании надеются, что нейросети позволят им и дальше игнорировать отсутствие стабильных локаторов и мусор в коде. Но без изменения самой архитектуры разработки ИИ-ассистент лишь маскирует неэффективность, превращаясь в дорогой пластырь на рваной ране легаси-кода. Инвестировать в поддержку того, что изначально спроектировано как нерентабельное — сомнительная стратегия для тех, кто умеет считать деньги.