Что получится
ИИ-агент для QA помогает команде быстрее находить дефекты: превращает требования в тест-кейсы, предлагает регрессионные сценарии, пишет черновики автотестов, анализирует падения, группирует flaky-тесты и готовит понятный отчет для разработчиков.
Важно: агент не должен "чинить" тесты удалением проверок, менять продуктовый код без задачи или автоматически принимать решение, что баг не баг. Его роль - ускорять QA-процесс, а не подменять ответственность инженера.
Где агент полезен
- Анализ требований и user stories.
- Подготовка чек-листов.
- Генерация тест-кейсов.
- Написание черновиков Playwright или Cypress тестов.
- Анализ скриншотов, видео и trace.
- Разбор падений в CI.
- Поиск flaky-тестов.
- Подготовка bug report.
- Проверка доступности базовых пользовательских сценариев.
- Регрессионный тест-план перед релизом.
Шаг 1. Выберите первый сценарий
Не начинайте с агента, который "сам тестирует все приложение". Лучше выбрать узкую задачу.
Хороший MVP:
- агент читает user story и делает чек-лист;
- агент пишет черновик E2E-теста для одного сценария;
- агент анализирует падение Playwright/Cypress в CI;
- агент готовит bug report по скриншоту и логу;
- агент ищет flaky-тесты в истории прогонов.
Для первой версии лучше всего подходит связка: чек-лист плюс черновик автотеста плюс анализ падений.
Шаг 2. Соберите входные данные
QA-агенту нужны не только страницы сайта, но и контекст.
Подключите:
- требования;
- user stories;
- макеты;
- список критических сценариев;
- тест-кейсы;
- баг-репорты;
- документацию API;
- список ролей пользователей;
- тестовые учетные записи;
- результаты прошлых прогонов;
- скриншоты и видео падений;
- правила качества команды.
Если требований нет, агент должен сначала задавать вопросы, а не придумывать критерии приемки самостоятельно.
Шаг 3. Опишите тестовую политику
Без правил агент будет писать слишком много хрупких тестов.
Зафиксируйте:
- какие сценарии покрываем E2E;
- какие проверки остаются на уровне unit или API;
- где нужны smoke-тесты;
- где нужен полный регресс;
- какие данные можно использовать;
- какие окружения доступны;
- какие действия запрещены;
- кто утверждает новые тесты;
- что делать с flaky-тестами.
Главное правило: автотест должен проверять поведение пользователя, а не внутреннюю верстку ради верстки.
Шаг 4. Сделайте карту критических сценариев
Сначала покрывайте то, что ломает бизнес.
Примеры критических сценариев:
- регистрация;
- логин;
- восстановление пароля;
- оформление заказа;
- оплата;
- отправка формы;
- поиск;
- фильтрация;
- создание заявки;
- изменение настроек;
- права доступа.
Для каждого сценария храните:
- роль пользователя;
- предусловия;
- шаги;
- ожидаемый результат;
- тестовые данные;
- уровень критичности;
- тип проверки: manual, API, E2E, visual.
Шаг 5. Подключите Playwright или Cypress
Для веб-приложений чаще всего выбирают Playwright или Cypress.
Playwright хорошо подходит, если нужны разные браузеры, параллельные прогоны, trace, сильные локаторы и тесты с несколькими контекстами. Cypress удобен для фронтенд-команд, которым нужен интерактивный runner, быстрый feedback и понятная отладка в браузере.
Не заставляйте агента выбирать инструмент вслепую. Он должен учитывать стек проекта, текущие тесты, CI, опыт команды и тип приложения.
Шаг 6. Дайте агенту правила локаторов
Хрупкие локаторы - частая причина плохих автотестов.
Правила:
- сначала использовать role, label, text, placeholder и alt text;
- использовать test id для стабильных контрактов;
- не привязываться к случайным CSS-классам;
- не выбирать первый попавшийся элемент;
- проверять уникальность локатора;
- не добавлять sleep без причины;
- ждать состояние интерфейса через assertions и явные условия.
Пример для Playwright:
await page.getByRole('button', { name: 'Сохранить' }).click();
await expect(page.getByText('Изменения сохранены')).toBeVisible();Такой тест ближе к поведению пользователя и обычно живет дольше, чем селектор по вложенности div.
Шаг 7. Генерируйте тест как черновик
Агент может написать черновик, но человек должен проверить смысл.
В черновике должны быть:
- название сценария;
- предусловия;
- тестовые данные;
- шаги;
- assertions;
- очистка данных;
- ссылки на требование;
- риск и ограничения.
Плохой тест просто кликает по странице. Хороший тест проверяет результат, который важен пользователю или бизнесу.
Шаг 8. Настройте безопасные права
QA-агенту не нужен полный доступ к production.
Разрешите:
- читать требования;
- читать тесты;
- создавать pull request с тестами;
- читать CI-логи;
- читать артефакты прогона;
- создавать bug report;
- комментировать задачу.
Ограничьте:
- изменение продуктового кода;
- удаление assertions;
- массовое обновление snapshots;
- запуск тестов на production без разрешения;
- изменение CI pipeline;
- закрытие багов;
- удаление тестов.
Если агент предлагает удалить тест, он должен объяснить причину и приложить замену или ссылку на изменение требований.
Шаг 9. Разбирайте падения в CI
После падения теста агент должен собрать факты.
Порядок:
- название теста;
- commit или pull request;
- окружение;
- браузер;
- ошибка;
- screenshot;
- video;
- trace;
- последние изменения;
- повторяемость;
- похожие падения.
Вывод должен быть не "тест упал", а одна из гипотез:
- реальный баг;
- изменение требований;
- нестабильные данные;
- проблема окружения;
- flaky-тест;
- неправильный locator;
- тест устарел.
Шаг 10. Делайте нормальный bug report
Bug report от агента должен быть пригоден для разработчика.
Формат:
- краткое название;
- окружение;
- шаги воспроизведения;
- фактический результат;
- ожидаемый результат;
- скриншот или видео;
- логи;
- severity;
- ссылка на тест;
- гипотеза причины;
- что проверить дальше.
Агент не должен маскировать неопределенность. Если причина не ясна, лучше написать "нужна проверка", чем уверенно обвинить конкретный модуль.
Шаг 11. Следите за flaky-тестами
Flaky-тест то проходит, то падает без изменения продукта. Он подрывает доверие к автотестам.
Сигналы:
- тест падает редко и в разных местах;
- повторный запуск проходит;
- ошибка связана с ожиданием элемента;
- падение зависит от скорости CI;
- данные не очищаются;
- есть гонки между запросами и UI.
Агент может группировать flaky-тесты, считать частоту падений и предлагать исправление: улучшить локатор, стабилизировать данные, добавить явное ожидание состояния или вынести сценарий на уровень API.
Шаг 12. Встройте агента в процесс релиза
Перед релизом агент может готовить QA-сводку.
В нее входят:
- какие сценарии покрыты;
- какие тесты прошли;
- какие тесты упали;
- какие падения повторные;
- какие баги открыты;
- какие риски остались;
- что нужно проверить вручную;
- можно ли выпускать релиз.
Финальное решение о релизе остается за командой. Агент только собирает картину и подсвечивает риски.
Минимальная архитектура
- Источник требований хранит user stories и acceptance criteria.
- Репозиторий хранит автотесты.
- CI запускает тесты и сохраняет артефакты.
- Test runner выполняет Playwright или Cypress.
- Отчетность собирает результаты, screenshots, videos и traces.
- QA-агент анализирует требования, тесты и падения.
- Approval нужен для новых тестов, удаления проверок и изменения pipeline.
Частые вопросы
Может ли агент сам писать автотесты?
Да, но лучше воспринимать их как черновики. Человек должен проверить, что тест действительно покрывает важное поведение, использует стабильные локаторы и не создает ложное чувство безопасности.
Что выбрать для старта: Playwright или Cypress?
Если в проекте уже есть один из инструментов, используйте его. Если начинаете с нуля, Playwright часто удобен для кроссбраузерных E2E-тестов и CI, а Cypress - для команд, которым важна интерактивная отладка фронтенда.
Можно ли агенту автоматически чинить падающие тесты?
Только в ограниченном режиме. Он может предложить patch, но не должен удалять assertions, ослаблять проверки или массово обновлять snapshots без review.
Как понять, что тест хороший?
Хороший тест проверяет важный пользовательский результат, имеет понятное имя, стабильные данные, надежные локаторы и ясные assertions. При падении понятно, что именно сломалось.
Что делать с flaky-тестами?
Их нужно отдельно учитывать, а не игнорировать. Агент может найти повторяющиеся flaky-падения, сгруппировать причины и предложить исправления, но решение должен проверить QA или разработчик.
