Интеграция Playwright/Selenium с LLM для автономного тестирования

Автономное тестирование: где ломается ручной регресс

Ручной регресс перестаёт успевать за частотой выпусков раньше, чем это становится видно в отчётах. Пока инженеры прогоняют закреплённый набор сценариев, в основную ветку входит ещё несколько изменений — и часть проверок выполняется уже против другой сборки. Задержка релиза растёт не линейно: каждая доработка добавляет кейсы, а время на полный прогон остаётся прежним.

Вторая точка отказа — поддерживаемость проверок. Один и тот же путь пользователя обрастает дублями в разных наборах, и при правке разметки изменения приходится вносить в каждый по отдельности. Падения разбирают вручную: тест упал — непонятно, сломался продукт или устарел сам сценарий, и на разбор уходит больше времени, чем на запуск.

Автономное тестирование меняет источник проверок. Генерация проверок идёт от постановки задачи и фактического поведения системы, а не от ручного переписывания шагов: сценарий подстраивается под изменившийся экран, дубли схлопываются, а к каждому падению прикладывается разбор причины. Связка Playwright или Selenium с языковой моделью даёт исполняемую проверку и вердикт, который читается без погружения в код теста, — устаревшие шаги помечаются отдельно, а не тихо падают.

Эффект на релизном цикле: полный прогон сокращается с дней до десятков минут, доля путей, подтверждённых автоматически, растёт, а ручной труд уходит из повторяющихся сценариев. При этом автономный контур не заменяет исследовательское тестирование — он снимает рутину, оставляя людям новые сценарии и спорные места. Разбираем, как это закрывается на практике — от сбора покрытия до разбора падений.

Что меняется после внедрения: покрытие и скорость

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

Прогон перестаёт быть событием на полдня: проверки распараллеливаются, и изменения получают вердикт за минуты, а не к вечеру. Это меняет поведение команды — правку отправляют на проверку сразу, а не копят пакетом к релизу, и ошибка находится в момент, когда её ещё дёшево исправить.

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

Вместе с этим уходит класс отказов «пропустили перед релизом»: критичные пути проходят целиком на каждом кандидате в выпуск, а не выборочно по списку, составленному вручную. Решение о выпуске опирается на отчёт по покрытию и историю прошлых падений, а не на «вроде проверяли». Устойчивость релизов становится измеримой величиной, а не ощущением.

Способы встраивания проверок: сравнение режимов

Режим проверок определяет, сколько ложных падений команда разбирает каждую неделю. Готовые инструменты автоматизации предсказуемы, но хрупки к правкам разметки; агент на базе языковой модели переживает изменения интерфейса, зато требует контроля корректности шагов. Сравнение подходов ниже — по устойчивости к изменениям, охвату сценариев и трудозатратам на поддержку.

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

Как проходит внедрение: этапы инженерной работы

Внедрение идёт короткими итерациями: каждая заканчивается рабочим стендом и набором проверок, который уже можно запускать. Так на любом шаге остаётся результат, пригодный к использованию, а не ожидание финальной сдачи.

1. Аудит сценариев. Разбираем регрессионные наборы и карту продукта, отбираем критичные пользовательские пути и помечаем, что закрывается автономным тестированием, а что осознанно остаётся за ручной проверкой.
2. Схема прогона. Фиксируем, где запускаются проверки, как изолируются данные и как между сценариями возвращается исходное состояние: иначе один упавший тест тянет за собой соседние.
3. Настройка окружений. Поднимаем стенды, тестовые учётные записи и данные, настраиваем Playwright и прогон в браузерах, которыми реально пользуется аудитория продукта.
4. Генерация проверок. Модель по описанию сценария и подсказкам о структуре страницы выдаёт черновик проверки, инженер правит его и оставляет только то, что переживёт ближайшие правки интерфейса.
5. Проверка устойчивости. Гоняем набор многократно на одном и том же коде и вычищаем шаги, дающие разный результат без изменений в продукте.
6. Приёмочная проверка. Сверяем автономный прогон с ручным на контрольных сценариях и убеждаемся, что намеренно внесённые дефекты действительно находятся.
7. Передача команде. Отдаём конфигурации, правила поддержки проверок и инструкцию по расширению набора — дальше команда ведёт его сама.

Артефакты внедрения: схемы, конфигурации, регламенты

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

• Схема проверок — карта критичных путей с приоритетами, списком предусловий и признаками, по которым сценарий считается пройденным или проваленным.
• Конфигурации запуска — профили для локального прогона, предрелизного контура и ночной регрессии: разные наборы сценариев и разный уровень строгости проверок.
• Политики доступа — выделенные учётные записи для прогонов, запрет изменяющих операций на продуктивных данных, хранение секретов вне кода и вне истории изменений.
• Документация по прогону — как читать отчёт, какие артефакты сохраняются при падении (снимок экрана, журнал, запись шагов) и как воспроизвести сбой на локальной машине.
• Регламент сопровождения — сроки разбора упавших сценариев, условия перевода теста в карантин, порядок обновления селекторов при изменении интерфейса.
• Правила развития набора — как добавлять новые сценарии, кто согласует их приоритет и по каким признакам тест удаляется как устаревший.

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

Кейс: как сократили ручной регресс на потоке заказов

Заказчик — интернет-магазин с потоком заказов и релизами каждые две недели. Регресс держался на ручном прогоне: около 320 проверок, полный проход занимал 8–10 часов работы двух инженеров и растягивался на несколько дней. Проверки не успевали за изменениями, и на релиз стабильно приходило 4–6 пропущенных дефектов — часть всплывала уже в оформлении заказа.

Мы оставили сценарии в Playwright как слой исполнения и надстроили над ними модель: она собирает шаги из текстового описания проверки, а при изменении вёрстки находит элемент по смыслу, а не по цепочке классов. Регресс запускается на каждое изменение кода и ночью по расписанию, результат приходит отчётом с шагами, снимками экрана и точкой падения.

Через два месяца после запуска: полный прогон — 35–40 минут вместо 8–10 часов, доля ручных проверок упала с 100% до 12% — вручную остались вычитка писем и вёрстка на редких устройствах, пропущенные дефекты на релиз — 0–1 вместо 4–6.

Отдельный эффект — стоимость поддержки: редизайн карточки товара больше не ломает десятки тестов, часть восстанавливается сама, остальное правится точечно. Новый сценарий собирается за 20–30 минут вместо половины дня: инженер описывает проверку словами, модель разворачивает её в шаги. Автономное тестирование стало частью релизного цикла, а не отдельным экспериментом.

Чем автономное тестирование отличается от классических автотестов

Классический автотест — заранее записанный сценарий: шаги, селекторы и ожидаемый результат заданы в коде. Пока интерфейс стабилен, прогон воспроизводим и даёт один и тот же вердикт. Ломается он там, где меняется разметка: селектор не находит элемент, и проверка падает не из-за дефекта, а из-за правки вёрстки.

Автономное тестирование начинается там, где вместо шагов задаётся цель и правила. Языковая модель получает описание сценария и состояние страницы, сама решает, куда нажать и что ввести, а после каждого действия сверяет результат с ожиданием. Элементы она находит по смыслу — по тексту, роли, соседним блокам, — поэтому косметическая правка разметки проверку не роняет. Генерация шагов идёт на каждом прогоне, а не один раз при написании.

Отсюда ключевое отличие — стоимость поддержки проверок. В классике инженер чинит селекторы после каждой правки интерфейса, и вместе с числом сценариев растёт эта доля. В автономном подходе правят описание цели и правила, код шагов переписывать не нужно.

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

Сомнения инженеров: доступы, данные, нестабильные проверки

Инженеры задают одни и те же вопросы перед пилотом: куда уходят данные, что с доступом к средам, как отличить реальный дефект от нестабильной проверки. Ниже — ответы без общих слов, на уровне конфигурации.

Нужны ли реальные тестовые данные?

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

Как боретесь с нестабильными проверками?

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

Что с правами доступа и поддержкой после передачи?

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

Обсудим задачу: что понадобится для старта работ

Чтобы взяться за автономное тестирование, полное техническое задание не нужно — достаточно короткого набора входных данных. Чем раньше мы видим доступы, стенды и перечень критичных сценариев, тем точнее оценка объёма работ и тем меньше допущений в плане внедрения: агент, настроенный на демонстрационных данных, ведёт себя иначе, чем на живом контуре с реальными ролями и состоянием базы.

• Репозиторий с текущими автотестами и права на отдельную ветку под конфигурацию агента.
• Тестовый контур, повторяющий боевой по структуре данных и наборам ролей, со своими учётными записями.
• Перечень критичных сценариев и правил: что считать верным результатом, а что — ложным срабатыванием.
• Регламент прогонов: по какому событию запускаем, с какой периодичностью, кто разбирает отчёт и в какие сроки.
• Доступ к журналам приложения и системе учёта задач — туда агент заводит дефекты с шагами воспроизведения.
• Согласованные ограничения: какие данные и операции не трогаем, где обязателен ручной подтверждающий шаг.
• Ответственный со стороны продукта, который разбирает спорные находки и подтверждает приёмку.

Опишите задачу в свободной форме — вернёмся с оценкой объёма, требованиями к доступам и планом внедрения по этапам.