Роль искусственного интеллекта в QA и AQA

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Главная задача этой статьи — проверить, существуют ли ИИ-инструменты, которые позволяют отказаться от написания тестов с нуля либо существенно сократить время на их реализацию.

В наши дни искусственный интеллект буквально везде. Появляются десятки статей про промптинг, ИИ-агентов, вайбкодинг, MCP-серверы, а также SaaS-сервисы, которые обещают автоматизировать почти любую деятельность.

Попробуем понять, могут ли ИИ-агенты взять на себя автоматизацию самой очевидной части разработки — тестирования, то есть QA.

Представим ситуацию, когда в команде нет ручного тестировщика, но при этом нужны E2E-тесты, чтобы поддерживать качество продукта, а ресурсов и желания на их написание и постоянное сопровождение нет.

На первый взгляд это идеальный сценарий для применения ИИ. Можно ли поручить ИИ генерацию E2E-тестов вместо ручного написания? Или разумнее воспользоваться готовым SaaS-решением для QA, чем писать и поддерживать собственный тестовый код?

Читайте также: Инструменты для автоматизации тестирования в 2026 году

SaaS-решения

Большинство SaaS-решений предоставляют функциональность, схожую с Playwright codegen. Например, вы кликаете по элементу — действие записывается; вводите строку в поле — это тоже записывается, и так далее. В конце вы сохраняете записанные шаги и можете воспроизводить их повторно. В результате получается стандартный E2E-тест с явно заданными шагами.
По сути, единственное отличие от Playwright codegen — отсутствие необходимости настраивать собственный CI/CD для запуска тестов. В целом этот подход не представляет особого интереса, и ИИ здесь не используется.

При этом существуют стартапы, которые позволяют описывать действия и проверки с помощью промптов. Один из примеров — Momentic.

Вам не нужно явно указывать, что логин вводится в инпут с id="username" или class="username". Вместо этого можно использовать более абстрактный промпт вроде: «введи значение в поле над полем пароля».

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

Звучит довольно перспективно.

Но есть и несколько недостатков:

1. Основной минус — у вас нет никакого кода. Все тесты хранятся внутри SaaS, поэтому вы не можете перенести их из одного сервиса в другой или запускать локально.
2. Каждый шаг обрабатывается ИИ, а значит, на выполнение уходит время. Это не прямой вызов команды вроде «кликни по кнопке с таким-то классом». Если в тест-кейсе больше 100 шагов, разница во времени становится заметной.
3. Инструмент всё ещё в стадии беты, публичных цен нет, но очевидно, что такие прогоны будут стоить дороже, чем собственный CI/CD.
4. Несмотря на поддержку сложных промптов, шаги всё равно приходится описывать вручную. Нельзя просто сказать: «проверь, что логин работает корректно».
   

Ещё один пример — Mabl. Это достаточно функциональный инструмент, но в контексте этой статьи нас больше всего интересует возможность генерации тестов по промпту.

Можно написать короткий промпт, например:

1. Go to  http://automationexercise.com
2. Verify that home page is visible successfully.
3. Sign up as a new user. This user is a woman and she is 33 years old and she is from Alaska. Use “super_secret” as her password. Fill out the rest required fields in the Sign up form with random values.
4. Verify that the user can see the orders page.

После этого Mabl может сгенерировать тестовый сценарий, состоящий уже из конкретных команд — например, кликов по кнопкам и ввода значений в поля.

На скриншоте ниже видно, как именно формируется тест: инструмент сам определяет последовательность шагов и финальные ассерты. Он понимает, как добраться до формы регистрации, и корректно выбирает титул «Mrs.», так как в промпте явно указано, что пользователь — женщина.

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

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

Ключевое отличие от предыдущего подхода в том, что SaaS обрабатывает промпт с помощью ИИ только один раз, после чего вы получаете сгенерированный тест с детализированными шагами, который этот же SaaS может выполнять уже без участия ИИ.

Какие есть минусы?

1. Основной недостаток заключается в том, что генерация шагов для заполнения простой формы (10–15 стандартных HTML-инпутов) может занимать больше 10 минут. При этом те же самые шаги можно записать в 5 раз быстрее, просто используя встроенный рекордер этого SaaS.
2. Кроме того, инструмент не всегда корректно работает с любыми промптами и любым пользовательским интерфейсом. Он может застрять в цикле или сгенерировать ошибочные шаги, после чего процесс генерации придётся начинать заново.
   

Есть и типичные недостатки SaaS-решений:

3. Цена. Запуск тестов через SaaS дороже, чем локально.
4. Отсутствие экспорта. Тесты нельзя перенести между разными SaaS-платформами или запускать локально.
   

Итог

В целом такие SaaS-решения выглядят многообещающе и действительно предлагают рабочие инструменты.

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

1. Для крупных проектов ситуация меняется: запуск сотен тестов в SaaS может быть дорогим, особенно если тесты нужно прогонять на каждый коммит в pull request’ах.
2. SaaS-тесты сложно поддерживать. В Playwright можно вынести страницы и элементы в общие компоненты и обновлять логику в одном месте — добавить асерт или новое поле. В SaaS подобные изменения придётся вносить в каждый тест отдельно.
3. SaaS-решения обычно медленнее локальных Playwright-тестов на собственном CI/CD. Использование промптов означает обращения к LLM по API, а генерация теста целиком через ИИ может занимать значительное время даже для простых сценариев.
   

Но что, если в команде есть разработчики, CI/CD уже настроен, а тесты запускаются на каждый коммит в GitHub? Можно ли в таком случае использовать ИИ, чтобы сократить объём тестового кода или вовсе отказаться от его написания?

Рассмотрим несколько вариантов — от наименее технически сложного к наиболее сложному:

1. тестирование, полностью основанное на промптах,
2. Playwright-тесты с использованием ИИ,
3. вайбкодинг с использованием Playwright MCP.
   

Все тесты были выполнены в августе 2025 года с использованием модели GPT-5.

Тестирование, основанное только на промптах

Существуют инструменты, которые позволяют описывать тест-кейсы в стиле BDD (Behavior-Driven Development). В этом случае E2E-тесты строятся исключительно на текстовых описаниях — без единой строки Playwright-кода.

BDD использует понятный человеку язык, чаще всего в формате сценариев «Given – When – Then», чтобы описывать требования и гарантировать, что ожидаемое поведение системы понятно всем участникам процесса. Фактически, писать такие тесты могут не только тестировщики, но и продакт-менеджеры, предметные эксперты и другие нетехнические специалисты.

Один из таких инструментов — Hercules. Это тестовый агент, который использует файлы Gherkin в качестве промптов для выполнения тестов.

• testzeus-hercules/README.md
• testzeus-hercules/docs/run_guide.md
  

Проект является open-source, но у него есть и коммерческая версия с пользовательским интерфейсом и круглосуточной поддержкой.

В общих чертах процесс выглядит так:

1. инструмент устанавливается как обычная Python-библиотека;
2. тест-кейс описывается в Gherkin-файле в формате BDD.
   

3. После этого Hercules запускается одной командой:

testzeus-hercules —input-file ./opt/input/pass_survey.feature —output-path ./opt/output —test-data-path ./opt/test_data —llm-model gpt-5 —llm-model-api-key sk-proj-…

4. После запуска агент последовательно выполняет шаги BDD-сценария: команды («кликнуть по кнопке “Add client”») и ассерты («должно отображаться уведомление “Client added successfully”»).

На каждом шаге делается скриншот страницы браузера. Затем этот скриншот вместе с текущим шагом BDD-теста отправляется в ИИ с функцией computer-use (см. OpenAI Platform). В ответ ИИ возвращает команду, например click(100, 200), которая затем выполняется.

Инструмент способен обрабатывать сложные промпты вроде «я залогинился, используя email = «your@email.com» и пароль = «test_password»». Он понимает, какие действия нужно выполнить для авторизации на сайте, как установить дату рождения через календарный виджет и т.д.

Ассерты обрабатываются по тому же принципу: скриншот отправляется в LLM вместе с формулировкой проверки.

Основные проблемы:

• Необходимо использовать модель рассуждений, а такая модель работает медленно. Например, проверка того, что в списке пользователей есть только один элемент, может занимать до 20 секунд.
• Для выполнения одного действия инструмент может делать до 5 попыток — например, при выборе значения в выпадающем списке.
• Инструмент нестабилен: он может корректно работать с календарным виджетом для выбора даты рождения, но при этом не справляться с выбором региона проживания.
• Большое количество обращений к ИИ API делает такие тесты дорогими: прогон сценария из 30–40 шагов может стоить порядка $1.
  

Тем не менее это всё равно выглядит впечатляюще. Возможность запускать BDD-тесты без единой строки кода ещё недавно казалась чем-то из области фантастики.

Стоит ли использовать этот подход сейчас? Потенциал у него есть, и автоматизация тестирования, скорее всего, будет двигаться именно в эту сторону. Но на текущем этапе решение не готово для продакшена: оно медленное, нестабильное и слишком дорогое. К этому подходу стоит вернуться примерно через год, когда появятся более мощные модели. В рамках этой статьи использовалась GPT-5.

Когда система сможет принимать корректные решения с первой попытки в большинстве случаев и выполнять шаги за 2–3 секунды, необходимость в Playwright-тестах может отпасть.

Playwright-тесты с использованием ИИ

ИИ можно встраивать и в обычные Playwright-тесты.

Если кратко, процесс выглядит так:

1. библиотека предоставляет функцию для вызова LLM;
2. при вызове функции делается скриншот страницы в браузере;
3. скриншот и текстовый промпт отправляются в ИИ с поддержкой computer-use (см. OpenAI Platform);
4. в ответ ИИ возвращает команду (например, click(100, 200)), которая затем выполняется в браузере.
   

По сути, логика практически идентична предыдущему подходу — «Тестирование, основанное только на промптах».

На данный момент доступны:

• платная библиотека ZeroStep
• open-source-аналог lucgagan/auto-playwright
  

Ниже приведён небольшой пример такого теста.

Суть подхода в том, что вместо обычных команд (click, fill, check) мы используем функцию auto(), которой передаём текстовый промпт.

С простыми промптами вроде «Введи что-нибудь в это поле» она справляется нормально, но с чуть более сложными, например «Авторизуйся, используя “your@email.com” как email и “test_password” как пароль», могут возникать сложности.

Чем это лучше подхода «Тестирование, основанное только на промптах»?

У того подхода есть два ключевых минуса: он нестабилен и работает очень медленно.

Тесты, созданные с помощью искусственного интеллекта, — это по сути обычные Playwright-тесты. Они выполняются быстро и в целом ведут себя предсказуемо.

Да, результат функции auto() не является стабильным на 100%: LLM может отвечать по-разному между прогонами, и выполнение запроса занимает время. Поэтому идея не в том, чтобы использовать её на каждом шаге, а только там, где она реально упрощает поддержку тестов.

Например, это может быть полезно при тестировании внешнего UI, который может обновляться в любой момент (локаторы, тексты, id), из-за чего невозможно использовать стабильные локаторы в тестовом коде.

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

Вайбкодинг с Playwright MCP

Мы подошли к самому трудоемкому и технически сложному варианту.

Если коротко, Model Context Protocol (MCP) предоставляет LLM набор инструментов. Playwright MCP Server, в свою очередь, предоставляет методы для работы с браузером: take_snapshot, browser_drag, browser_select_option и другие.
Например, метод take_snapshot преобразует скриншот страницы браузера в формат Markdown перед отправкой в LLM. Это позволяет модели понять, какие локаторы используются на странице, и на основе этого сгенерировать корректный тестовый код.

Чтобы подключить MCP-сервер, достаточно добавить несколько строк в конфигурацию IDE, cloud-приложения и т.д.:

"servers": {<br>  "playwright": {<br>      "command": "npx",<br>        "args": [<br>	    "@playwright/mcp@latest"<br>        ],<br>	"type": "stdio"<br>      }<br>},<br>"inputs": []

Затем введите промпт с базовым контекстом:

​​- You are a playwright test generator.
- You are given a scenario and you need to generate a playwright test for it.
- DO NOT generate test code based on the scenario alone. 
- DO run steps one by one using the tools provided by the Playwright MCP.
- Only after all steps are completed, emit a Playwright TypeScript test that uses @playwright/test based on message history
- Save generated test file in the tests directory
- Execute the test file and iterate until the test passes

После этого можно попросить ИИ-агента сгенерировать нужный тест-кейс. Для этого нужно передать корректный промпт в ИИ-чат — это может быть чат в Copilot, Cursor IDE, Claude App и т. д.

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

Мы будем использовать промпт из примера с SaaS:

Generate a Playwright test for following scenario:
1. Go to  http://automationexercise.com
2. Verify that home page is visible successfully
3. Sign up as a new user. This user is a woman and she is 33 years old and she is from Alaska. Use “super_secret” as her password. Fill out the rest required fields in the Sign up form with random values.

Обратите внимание: мы явно не указываем, как именно нужно заполнять форму. Например, мы не пишем, что нужно выбрать обращение “Mrs.” — агент должен понять это из того, что пользователь женщина. Аналогично, агент должен корректно определить дату рождения на основе текущего года и возраста пользователя (33 года).

Ниже приведен пример шагов, выполняемых ИИ-агентом для генерации тестового кода. Мы используем модель с рассуждениями (reasoning-модель) (GPT-5), которая решает сложные задачи, разбивая их на более мелкие шаги, показывая ход рассуждений и итеративно находя решение. Этот процесс часто называют цепочкой рассуждений (chain-of-thought reasoning).

ИИ-агент смог перейти к регистрационной форме, показанной ниже, и заполнить ее.

В результате был сгенерирован код теста. ИИ-агент сделал это с первого раза, потратив примерно 6 минут.

Это самый простой сценарий, без ошибок. Если при отправке формы возникает ошибка, агент способен принимать ситуативные решения:

1. Используется уже занятый email? — агент добавит уникальный идентификатор и попробует отправить форму повторно.
2. Для отправки формы необходимо принять пользовательское соглашение? — агент проанализирует сообщение об ошибке и отметит чекбокс соглашения.
3. Случайное значение для поля формы оказалось слишком длинным? — агент подставит более короткое значение.
   

Основной недостаток в том, что агент генерирует код с нуля. Он не использует базовые классы или общие абстракции по умолчанию. Сначала агент проходит сценарий из промпта в браузере: находит форму регистрации → заполняет и отправляет её → выполняет проверки. И только после этого генерирует Playwright-тест.

Сгенерированный код описывает все действия в браузере: getByRole, getByText, click, fill и т.д. По сути, это тот же самый код, который можно получить с помощью Playwright codegen. Когда мы запускаем рекордер и выполняем действия в браузере, каждое действие записывается и генерируется соответствующая команда, например: «page.getByRole(“textbox”, { name: «Password» }).fill(«some_password»)»

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

Можно ли это исправить?

Рассмотрим класс страницы логина. В нём описаны локаторы и методы для заполнения и отправки формы. Другими словами, в этом классе содержится общая логика, которая повторяется во всех тестах.

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

That's correct. However, the test you generated in the spec doesn't 
use a Page class. Take a look at the test in the signin spec 
file @signin.spec.ts . It uses the SignInPage class @SignInPage.ts,
so the code in the test simply calls methods of that class.

Generate a similar class for the signup test case @signup.spec.ts which 
you generated before, and rewrite the generated code to use that class.

И… это работает! На скриншоте чата Cursor ниже можно увидеть, как агент создаёт новый класс SignUpPage.

После внесённых изменений агент запускает обновлённый тест, чтобы убедиться, что ошибок нет. Если тест завершается с ошибкой, агент анализирует сообщение об ошибке от Playwright и корректирует код. При этом он объясняет, в чём видит причину ошибки и как планирует её исправить.

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

Результат не идеален, но создание заняло всего несколько минут, и получилось с первой попытки. Ниже на скриншоте показан тест после рефакторинга с использованием класса SignUpPage.

Разумеется, можно попросить агента доработать или расширить сгенерированный класс, добавить дополнительные проверки и создать больше тестов на его основе.

Да, это и есть настоящий вайбкодинг. Основу подхода составляют контекст проекта (файлы, документация, конфиги) и промпт. Важно также отметить, что для вайбкодинга E2E-теста необходим Playwright MCP сервер. Без него агенту будет трудно понять структуру страницы, и он будет угадывать селекторы, что приведёт к плохому или неработающему коду.

Основные выводы

Некоторые SaaS-решения выглядят многообещающе, но есть мнение, что их клиентами становятся компании, у которых нет собственной команды разработки или ресурсов для настройки CI/CD с E2E-тестами.

E2E-тестирование только на основе промптов, без Playwright-кода, а лишь с BDD-промптами, пока не готово к полноценному использованию.

Главные проблемы:

• Стабильность: текущие ИИ-агенты могут обрабатывать сложные промпты, но не дают стабильных результатов.
• Время: выполнение шагов и проверок занимает слишком много времени.
• Стоимость: такие тесты делают большое количество вызовов к LLM.
  

ИИ-тесты, где агент выполняет простые команды (например, клик по кнопке входа), полезны при тестировании внешних UI, которые часто меняются. Для собственного интерфейса это, как правило, малоэффективно.

На самом деле, E2E-тест можно вайбкодить, и ИИ-агент на современном уровне LLM (GPT-5 и выше) сделает это быстро и эффективно. Тем не менее, вайбкодинг всё ещё остаётся программированием.

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

Перевод статьи «AI in QA/AQA».