AI-модель генерирует наиболее вероятное продолжение твоего ввода: расплывчатый промпт "напиши Playwright-тест для логина" выдаёт скелет с плейсхолдерами YOUR_URL и CSS-селекторами, потому что именно так выглядит большинство обучающих данных. Тот же запрос с ролью, конкретным контекстом и явными ограничениями на типы локаторов даёт код который можно вставить напрямую. Статья разбирает четырёхчастную структуру промпта, конкретные инструкции которые предотвращают типичные ошибки при генерации тестов, промпты для code review и отладки, и что делать когда вывод скатывается к универсальным паттернам после нескольких итераций.

Почему качество вывода AI зависит от тебя

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

Модель не знает:

  • Какой фреймворк ты используешь
  • Как выглядит твоя кодовая база
  • Какую степень детализации ты хочешь
  • Что ты уже пробовал
  • В каких ограничениях ты работаешь

Когда получаешь плохой вывод, первый вопрос не "эта модель плохая?", а "дал ли мой промпт модели то что ей нужно для хорошей работы?"

Четырёхчастная структура промпта

Рабочий промпт для QA-задач обычно состоит из четырёх компонентов. Не всегда нужны все четыре, но когда вывод плохой, как правило один из них отсутствует.

Роль. Скажи модели каким экспертом она должна быть. "Ты старший QA automation-инженер" или "Ты TypeScript-эксперт специализирующийся на архитектуре Playwright-тестов" меняет регистр и глубину вывода. Контекст. Опиши ситуацию. Фреймворк, язык, тип приложения, ограничения. Чем конкретнее, тем лучше. Задача. Сам запрос, сформулированный точно. Не "напиши тест", а "напиши Playwright-тест на TypeScript который входит через storageState и проверяет что в шапке дашборда отображается имя пользователя". Формат. Как ты хочешь получить вывод. Только код? Код с комментариями? Сначала краткое объяснение? Таблицей? Укажи это, иначе получишь то что модель выдаёт по умолчанию.

Пример плохого промпта:

"Напиши Playwright-тест для логина"

Тот же промпт со всеми четырьмя компонентами:

"Ты старший QA automation-инженер. Я работаю над Playwright TypeScript-проектом с паттерном Page Object Model. Страница логина находится по адресу https://lab.becomeqa.com, использует форму с email и паролем, после успешного входа редиректит на /dashboard. Напиши тест который: входит с тестовыми учётными данными из переменных окружения, проверяет что URL изменился на /dashboard, проверяет что заголовок с текстом 'My Travel Items' виден. Используй только локаторы getByRole и getByLabel. Без комментариев в коде."

Второй промпт даёт код который можно вставить напрямую. Первый даёт скелет с плейсхолдерами.

Промпты для генерации тестов

При генерации Playwright-тестов наиболее частые проблемы:

Универсальные локаторы. AI по умолчанию берёт то что видел чаще всего в обучающих данных, а там много CSS-селекторов. Явно запрети их.
"Используй только локаторы getByRole, getByLabel, getByPlaceholder или getByTestId. Не используй CSS-селекторы или XPath."
Мало ассертов. Сгенерированные тесты часто имеют один ассерт в конце. Реальные тесты требуют большего.
"Добавляй ассерты на каждом значимом шаге, а не только в финальном состоянии. Проверяй промежуточные состояния там где они важны."
Нет контекста для сценариев с ошибками. Если тестируешь ошибочный сценарий, укажи это явно.
"Напиши тест для случая когда пользователь отправляет форму с пустым полем email. Проверь что сообщение об ошибке 'Email is required' появляется под полем email."
Захардкоженные тестовые данные. Предотвращай это заранее.
"Используй process.env для учётных данных. Не хардкодь имена пользователей, пароли или URL. Используй ссылки на переменные окружения."

Генерация тестов из пользовательской истории

Этот паттерн промпта особенно полезен. Вставляй пользовательскую историю напрямую и запрашивай тесты:

"Ты QA automation-инженер. Вот пользовательская история:
>
'Как залогиненный пользователь, я хочу добавить новый элемент в свой список путешествий чтобы отслеживать что нужно собрать.'
>
Приложение находится по адресу https://lab.becomeqa.com. Напиши Playwright TypeScript-тесты которые покрывают: happy path (элемент добавлен и появляется в списке), добавление дубликата, добавление элемента с именем превышающим лимит символов. Используй локаторы getByRole. Один ассерт на тест который проверяет конкретный результат. Верни только код тестов."

Генерация тестовых данных

При генерации тестовых данных синтаксис Faker.js меняется между версиями и AI-модели иногда придумывают названия методов. Зафиксируй версию:

"Создай TypeScript-фабричную функцию которая создаёт случайный объект пользователя с полями: email (правильный формат), firstName, lastName, password (минимум 8 символов, одна заглавная, одна цифра). Используй только синтаксис @faker-js/faker v8. Верни только функцию."

Промпты для code review

Code review с помощью AI QA-инженеры используют реже чем стоило бы. Он особенно хорош в нахождении вещей которые легко пропустить при первом чтении.

Review качества тестов

"Проверь этот Playwright-тест на: захардкоженные ожидания (page.waitForTimeout), CSS-селекторы, отсутствующие ассерты, тесты зависящие от порядка выполнения, и любые практики снижающие стабильность тестов. Перечисли каждую проблему с номером строки и объяснением почему это проблема."

Review соответствия Page Object Model

"Я строю Page Object Model на TypeScript. Вот мой базовый класс страницы и один page-объект. Проверь: все ли селекторы находятся в классе страницы (не в тестах), правильно ли action-методы возвращают промисы, следует ли конструктор паттерну, каких методов не хватает в классе судя по тому что импортируется. Предложи конкретные дополнения."

Проверка качества локаторов

"Посмотри на эти локаторы из моих Playwright-тестов. Для каждого скажи: хрупкий ли он (скорее всего сломается при редизайне UI)? Если да, предложи более стабильную альтернативу с семантическими локаторами."

Промпты для отладки

Когда тест падает и непонятно почему, AI может помочь, но нужно дать ему вывод падения, а не только код.

Шаблон для запроса помощи в отладке

"Этот Playwright-тест падает. Вот:
1. Код теста
2. Полное сообщение об ошибке и стек-трейс
3. Что приложение должно делать
>
[вставь каждый пункт]
>
Каковы наиболее вероятные причины этого падения? Перечисли их в порядке вероятности и для каждой объясни что нужно проверить."

Сообщение об ошибке критично. Без него модель гадает. С ним она часто точно указывает на проблему: отсутствующий await, локатор который не совпадает, проблема с таймингом.

Диагностика флакающего теста

"Этот тест проходит примерно в 70% случаев и падает в 30% с такой ошибкой: [ошибка]. Тест делает: [описание сценария]. Каковы вероятные причины этого нестабильного падения в Playwright? Что бы ты проверил первым?"

Промпты для документации

Генерация документации для существующего кода тестов: одно из наиболее ценных применений AI в QA. Никто не любит её писать, это занимает время, а AI делает это достаточно хорошо.

Генерация README тест-сьюта

"Напиши раздел README для этой директории с Playwright-тестами. Включи: что покрывает сьют, предварительные требования (нужные переменные окружения, шаги настройки), как запустить все тесты, как запустить конкретный файл, как запустить в режиме отладки. Основывайся на этом playwright.config.ts и этом примере тест-файла: [вставь оба]"

Сводка покрытия тестами

"Вот мои Playwright-тест файлы. Для каждого файла напиши одно предложение описывающее что он тестирует. Затем напиши сводный абзац о том что покрыто и чего не хватает для типичного веб-приложения с логином, управлением данными и экспортом."

Генерация баг-репорта из падающего теста

"Этот Playwright-тест падает и мне нужно написать баг-репорт. Вот тест, ошибка и скриншоты. Напиши баг-репорт в формате: Заголовок, Окружение, Шаги воспроизведения, Ожидаемый результат, Фактический результат, Серьёзность."

Промпты для обучения

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

"Объясни как работает storageState в Playwright на конкретном примере где тест-сьют имеет роли admin и обычный пользователь. Покажи setup-файл который генерирует состояния и тест использующий каждую роль. Используй TypeScript."
"Я понимаю как работает page.route() для простого мокинга. Объясни как использовать route.fallback() для частичного мока API, пропуская одни запросы на реальный бэкенд и перехватывая только конкретные. Покажи конкретный пример."

Конкретное ограничение заставляет модель идти дальше вводного объяснения к части которая реально полезна.

Когда итерировать, а когда начинать заново

После получения вывода от AI есть два варианта: итерировать его или начать заново с лучшим промптом.

Итерируй когда структура правильная, но что-то конкретное не так. Задавай точечные уточняющие вопросы вроде «измени локатор в строке 8 на getByLabel вместо getByPlaceholder», «добавь ассерт после отправки формы который проверяет что toast с успехом виден» или «вынеси хелпер логина в отдельную функцию». Начинай заново когда общий подход неверен: модель сгенерировала JavaScript когда ты хотел TypeScript, сделала тесты без Page Object когда ты хотел POM, или полностью неверно поняла сценарий тестирования. В таком случае лучший начальный промпт быстрее чем попытки скорректировать курс.

Хорошая эвристика: если итерировал три раза и всё ещё исправляешь структурные проблемы, начинай заново с более детальным промптом.

Контекстные окна и длинные разговоры

AI-инструменты теряют контекст в длинных разговорах. После 20+ обменов туда-обратно модель может "забыть" то что было установлено в начале: конвенцию локаторов которую ты указал или структуру классов которую просил соблюдать.

Три практики помогают:

Веди библиотеку промптов. Для типовых задач (создать тест, сревьюить page-объект, написать баг-репорт) сохраняй лучшие промпты. Не переписывай их каждый раз. Копируй и адаптируй. Начинай новый разговор для каждой задачи. Многоразовый контекст в одном разговоре создаёт путаницу в другом. Короткие сфокусированные разговоры дают лучший вывод чем растянутые сессии. Повторяй ключевые ограничения если вывод смещается. Если модель начинает использовать CSS-селекторы после того как ты ей это запретил, напомни явно: "Помни: только getByRole, getByLabel, getByPlaceholder, getByTestId. Никаких CSS-селекторов."

Что AI-инструменты не могут делать для QA

Понимание ограничений предотвращает разочарование и помогает знать когда прекратить попытки.

Они не запускают твои тесты. Модель не имеет доступа к твоему браузеру, приложению или тест-раннеру. Она может написать код который по её мнению сработает, но проверить не может. Они не видят твоё живое приложение. Без настроенного Playwright MCP модель понятия не имеет как выглядит твой UI. Она пишет тесты против воображаемой версии твоего приложения основанной на том что ты описал. Если описание неполное, сгенерированные локаторы будут неверными. Они галлюцинируют детали API. AI-инструменты иногда генерируют вызовы методов Playwright которых не существует, или используют реальные методы с неверными сигнатурами параметров. Всегда проверяй сгенерированный код по документации Playwright перед коммитом. Они не знают конвенций твоей команды. Если не вставить реальный код для контекста, модель не знает используют ли в вашей команде фабрики или фикстуры для тестовых данных, как работает базовый класс страницы и как выглядит структура импортов. Давай примеры. Они не принимают решения о покрытии. "Что тестировать?" требует понимания рисков фичи, скорости команды, что падало в продакшне и какой допустимый уровень риска. AI может предлагать что тестировать, но решения о покрытии остаются за тобой.

Личная библиотека промптов

Со временем собирай работающие промпты. Храни их в markdown-файле, Notion-странице или папке .claude с командами в проекте.

Полезные категории для наполнения:

  • Создать новый тест по описанию
  • Проревьюить тест-файл на качество
  • Сгенерировать тестовые данные с Faker
  • Написать Page Object-класс по описанию страницы
  • Отладить ошибку Playwright
  • Создать баг-репорт из падающего теста
  • Обобщить пробелы в покрытии тестами
  • Создать YAML CI-воркфлоу для Playwright

Каждый промпт: небольшая инвестиция в стабильное качество. Не нужно заново придумывать подход каждый раз когда садишься работать с AI-инструментом.

→ See also: ИИ в QA в 2026 году: что реально полезно, а что просто хайп | Использование ChatGPT для генерации тест-кейсов: практическое руководство для QA | GitHub Copilot для QA-инженеров: для чего он реально полезен | Инструменты генерации тестов с ИИ: что реально работает в 2026