20 готовых промптов для тестировщика

ChatGPT и другие AI-ассистенты могут заметно ускорить рутинную работу тестировщика.

Но есть проблема.

Запрос:

Напиши тесты для формы регистрации.

скорее всего даст такой же общий ответ.

А хороший промпт должен объяснить AI:

• что именно мы тестируем;
• какой контекст нужно учитывать;
• что требуется получить;
• в каком формате нужен результат;
• какие ограничения нельзя игнорировать.

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

Ниже — 20 готовых промптов для Manual QA. Их можно использовать в ChatGPT, Claude, Gemini и других AI-ассистентах, меняя данные в квадратных скобках под свой проект.

Как пользоваться этими промптами

Необязательно копировать каждый промпт слово в слово.

Лучший результат обычно получается, если добавить реальные данные из задачи:

Плохо:

Протестируй регистрацию.

Лучше:

Пользователь регистрируется по email и паролю. Email должен быть уникальным. Пароль — от 8 до 64 символов, минимум одна цифра и одна заглавная буква. После регистрации пользователю отправляется письмо для подтверждения email.

Чем больше полезного контекста получает AI, тем меньше ему приходится додумывать требования.

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

---

1. Сгенерировать тест-кейсы по требованиям

Одна из самых очевидных задач для AI — получить первоначальный набор тест-кейсов из требований или User Story.

Промпт:

Ты Senior QA Engineer.

Проанализируй требование:

[ВСТАВЬ ТРЕБОВАНИЕ]

Составь набор функциональных тест-кейсов.

Обязательно включи:

• позитивные сценарии;
• негативные сценарии;
• граничные значения;
• альтернативные сценарии;
• проверки валидации;
• потенциальные edge cases.

Для каждого тест-кейса укажи:

1. название;
2. предусловия;
3. шаги;
4. ожидаемый результат;
5. приоритет.

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

Последняя инструкция особенно полезна.

Без нее AI иногда начинает самостоятельно решать, как должна работать система, хотя в реальном проекте эти вопросы следовало бы задать аналитику или Product Owner.

---

2. Превратить User Story в тест-кейсы

Если команда работает с User Stories, можно использовать более специализированный запрос.

Промпт:

Выступи в роли QA Engineer.

User Story:

[USER STORY]

Acceptance Criteria:

[ACCEPTANCE CRITERIA]

На основе этих данных подготовь тест-кейсы.

Раздели проверки на:

• Happy Path;
• Negative;
• Boundary;
• Validation;
• Permissions;
• Error Handling.

Для каждого тест-кейса укажи шаги и Expected Result.

Дополнительно найди сценарии, которые прямо не описаны в Acceptance Criteria, но могут привести к ошибкам.

Не считай свои предположения требованиями — пометь их отдельно.

Такой промпт полезен еще до начала тестирования: иногда AI помогает заметить пробелы в Acceptance Criteria.

---

3. Сделать чек-лист для новой функциональности

Не для каждой задачи нужны подробные тест-кейсы.

Иногда быстрее работать по чек-листу.

Промпт:

Составь подробный QA-чек-лист для следующей функциональности:

[ОПИСАНИЕ ФУНКЦИОНАЛЬНОСТИ]

Сгруппируй проверки по категориям:

• основной функционал;
• негативные сценарии;
• валидация;
• UI;
• usability;
• права доступа;
• ошибки и сообщения пользователю;
• совместимость;
• интеграции;
• данные.

Каждый пункт сформулируй как короткую конкретную проверку.

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

---

4. Найти проверки, которые тестировщик мог забыть

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

Промпт:

Представь, что ты проводишь review тестового покрытия.

Функциональность:

[ОПИСАНИЕ]

Мой текущий чек-лист:

[ЧЕК-ЛИСТ]

Найди сценарии, которые я мог пропустить.

Особое внимание удели:

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

Не повторяй проверки, которые уже есть в моем списке.

Для каждой новой проверки коротко объясни, какой риск она покрывает.

Именно такой сценарий часто полезнее простой генерации тест-кейсов.

Сначала думает тестировщик. Потом AI выступает в качестве второго ревьюера.

---

5. Найти граничные значения

AI можно использовать как помощника при применении Boundary Value Analysis.

Промпт:

Проанализируй следующие правила валидации:

[ПРАВИЛА]

Определи все числовые, текстовые и логические границы.

Для каждой границы предложи тестовые значения:

• непосредственно перед границей;
• на границе;
• непосредственно после границы.

Если применимо, добавь минимальное и максимальное допустимое значение.

Результат представь таблицей:

Параметр | Ограничение | Тестовое значение | Почему проверяем | Ожидаемый результат.

Например, если допустимый возраст находится между 18 и 100 годами, логично получить проверки для 17, 18, 19, 99, 100 и 101.

---

6. Применить классы эквивалентности

Еще один способ быстро получить хорошие тестовые данные.

Промпт:

Используя технику Equivalence Partitioning, разбей входные данные на классы эквивалентности.

Требования:

[ТРЕБОВАНИЯ]

Для каждого поля укажи:

• валидные классы;
• невалидные классы;
• пример тестового значения;
• ожидаемый результат.

После этого предложи минимальный набор тестов, который покрывает все найденные классы.

Это особенно удобно для форм с большим количеством полей.

---

7. Протестировать форму регистрации

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

Промпт:

Ты тестируешь форму регистрации пользователя.

Поля и правила:

[ОПИШИ ПОЛЯ И ВАЛИДАЦИЮ]

Составь максимально практичный чек-лист.

Проверь:

• каждое поле отдельно;
• обязательность;
• минимальную и максимальную длину;
• пробелы;
• Unicode;
• специальные символы;
• copy/paste;
• дубликаты пользователей;
• существующий email;
• пароль;
• подтверждение пароля;
• сообщения об ошибках;
• повторную отправку формы;
• двойной клик;
• обновление страницы;
• Back в браузере;
• успешную регистрацию;
• подтверждение email, если оно предусмотрено.

Раздели результат на Critical, High, Medium и Low priority.

Можно убрать из запроса ненужные пункты или добавить особенности конкретного продукта.

---

8. Протестировать авторизацию

Промпт:

Подготовь чек-лист тестирования Login Form.

Система поддерживает:

[ОПИСАНИЕ АВТОРИЗАЦИИ]

Проверь не только правильный и неправильный пароль, но и:

• пустые значения;
• регистр;
• пробелы;
• длинные значения;
• блокировку аккаунта;
• повторные попытки;
• Remember Me;
• logout;
• несколько вкладок;
• несколько устройств;
• истечение сессии;
• изменение пароля;
• восстановление пароля;
• поведение старой сессии после изменения пароля.

Если некоторые проверки нельзя определить из требований, перечисли вопросы для аналитика отдельно.

---

9. Составить exploratory testing charter

AI пригодится и для исследовательского тестирования.

Промпт:

Создай Exploratory Testing Charter для функциональности:

[ФУНКЦИОНАЛЬНОСТЬ]

Формат:

Mission — что исследуем.

Risks — основные риски.

Areas — какие части системы проверить.

Test Ideas — идеи проверок.

Data — какие тестовые данные подготовить.

Tools — какие инструменты могут понадобиться.

Questions — что необходимо уточнить.

Ограничь сессию примерно 60 минутами и расставь проверки по приоритету.

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

---

10. Найти проблемы в требованиях

AI может выступить в роли дополнительного участника requirement review.

Промпт:

Проведи QA-review следующего требования:

[ТРЕБОВАНИЕ]

Найди:

• неоднозначные формулировки;
• отсутствующие ограничения;
• противоречия;
• неопределенные Expected Results;
• отсутствующие Error Cases;
• непонятные бизнес-правила;
• неописанные состояния;
• потенциальные проблемы с правами доступа.

Не исправляй требования самостоятельно.

Вместо этого сформулируй конкретные вопросы, которые QA должен задать аналитику, разработчику или Product Owner.

Например, требование:

Результаты поиска должны отображаться быстро.

сразу должно вызвать вопрос:

что в данном случае означает «быстро»?

500 мс? Одна секунда? Три секунды?

---

11. Превратить заметки в хороший баг-репорт

Очень практичный сценарий.

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

Промпт:

Преобразуй мои заметки в профессиональный баг-репорт.

Мои заметки:

[ВСТАВЬ ЗАМЕТКИ]

Если информация присутствует, сформируй:

Title

Environment

Preconditions

Steps to Reproduce

Actual Result

Expected Result

Reproducibility

Severity

Дополнительная информация

Не придумывай отсутствующие шаги или результаты.

Если важных данных не хватает, после баг-репорта перечисли, что именно мне нужно дополнительно проверить.

---

12. Улучшить название бага

Хороший Title должен позволять понять проблему еще до открытия тикета.

Промпт:

Предложи 5 вариантов короткого и информативного Title для бага.

Проблема:

[ОПИСАНИЕ]

Используй структуру:

[Где] + [что происходит] + [при каком условии]

Не используй слова:

• broken;
• doesn’t work;
• bug;
• problem;
• incorrect,

если можно конкретно описать фактическое поведение.

Максимум 120 символов.

Вместо:

Login doesn’t work

можно получить что-то вроде:

Login page returns 500 error after submitting valid credentials with Remember Me enabled

Уже намного информативнее.

---

13. Проверить качество готового баг-репорта

Промпт:

Проведи review моего баг-репорта:

[БАГ-РЕПОРТ]

Проверь:

• понятно ли название;
• можно ли воспроизвести баг по шагам;
• нет ли лишних шагов;
• указан ли Actual Result;
• указан ли Expected Result;
• достаточно ли контекста;
• понятно ли окружение;
• нет ли субъективных формулировок;
• не смешано ли несколько разных багов в одном тикете.

Сначала перечисли проблемы.

Затем предложи улучшенную версию баг-репорта.

Не добавляй факты, которых нет в исходном описании.

---

14. Определить Severity

Приоритет обычно зависит от бизнеса и команды, поэтому его не всегда разумно отдавать AI.

Но Severity модель может помочь предварительно оценить.

Промпт:

Помоги оценить Severity дефекта.

Описание:

[ОПИСАНИЕ БАГА]

Контекст:

[ГДЕ ПРОИСХОДИТ И СКОЛЬКО ПОЛЬЗОВАТЕЛЕЙ ЗАТРАГИВАЕТ]

Используем уровни:

Blocker
Critical
Major
Minor
Trivial

Для каждого возможного уровня объясни критерии.

Затем укажи наиболее подходящий уровень для описанной ситуации и какие дополнительные данные могут изменить оценку.

Не определяй Priority — это отдельная бизнес-оценка.

---

15. Подготовить тестовые данные

Промпт:

Подготовь набор тестовых данных для проверки:

[ПОЛЕ ИЛИ ФУНКЦИОНАЛЬНОСТЬ]

Требования:

[ОГРАНИЧЕНИЯ]

Создай примеры для:

• валидных данных;
• невалидных данных;
• минимальных значений;
• максимальных значений;
• пустого значения;
• пробелов;
• Unicode;
• кириллицы;
• латиницы;
• специальных символов;
• очень длинных значений;
• необычных, но допустимых значений.

Для каждого примера укажи ожидаемое поведение системы.

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

---

16. Протестировать API

AI может помочь Manual QA подготовить набор API-проверок, даже если тестировщик пока только осваивает Postman.

Промпт:

Выступи как API QA Engineer.

Endpoint:

[METHOD + URL]

Request:

[REQUEST]

Expected Response:

[RESPONSE / API DOCUMENTATION]

Составь проверки для этого endpoint.

Рассмотри:

• успешный запрос;
• обязательные параметры;
• отсутствующие параметры;
• неправильные типы данных;
• boundary values;
• authorization;
• invalid token;
• expired token;
• HTTP status codes;
• response body;
• headers;
• повторные запросы;
• idempotency, если применимо;
• несуществующие ресурсы;
• некорректный JSON;
• очень большие значения.

Для каждой проверки укажи Request, Expected Status и Expected Result.

Не придумывай поведение, которого нет в предоставленной API-документации.

---

17. Объяснить непонятный API-response

Еще один удобный сценарий для Junior QA.

Промпт:

Я Manual QA и изучаю API.

Объясни следующий response простыми словами:

[JSON RESPONSE]

Расскажи:

1. что означает каждое поле;
2. какие значения стоит проверить;
3. какие поля могут быть обязательными;
4. какие проверки типов данных возможны;
5. какие подозрительные места ты видишь.

Не утверждай, что поле является обязательным, если это невозможно определить без API specification.

Последняя строка защищает от очень распространенной проблемы: AI легко может принять предположение за факт.

---

18. Получить SQL-запрос для проверки данных

AI удобно использовать не только для получения готового запроса, но и как SQL-наставника.

Промпт:

Я QA Engineer и хочу проверить данные в БД.

Схема таблиц:

[ОПИСАНИЕ ТАБЛИЦ]

Мне нужно проверить:

[ЧТО НУЖНО НАЙТИ]

Напиши SQL-запрос.

После запроса простыми словами объясни:

• что делает каждая его часть;
• зачем используются JOIN/WHERE/GROUP BY, если они присутствуют;
• какой результат я должен получить;
• как дополнительно проверить корректность результата.

Не используй DELETE, UPDATE или другие изменяющие данные команды.

Последняя инструкция особенно полезна начинающим специалистам, чтобы случайно не превратить «проверку данных» в весьма запоминающийся рабочий день.

---

19. Составить regression checklist

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

Промпт:

Помоги составить Regression Checklist после изменения:

[ОПИСАНИЕ ИЗМЕНЕНИЯ]

Известные связанные части системы:

[КОМПОНЕНТЫ]

Сначала определи потенциальный Impact Area.

Затем предложи:

• Critical regression checks;
• High priority checks;
• Medium priority checks.

Учитывай:

• прямую функциональность;
• связанные функции;
• данные;
• API;
• роли пользователей;
• интеграции;
• старые сценарии;
• backward compatibility.

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

Такой подход значительно полезнее запроса:

Напиши regression tests.

Потому что модель вынуждена связывать проверку с конкретным риском.

---

20. Попросить AI сыграть роль QA-ревьюера

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

Промпт:

Выступи в роли второго QA Engineer, который проводит review моей работы.

Контекст задачи:

[КОНТЕКСТ]

Требования:

[ТРЕБОВАНИЯ]

Мой результат:

[ТЕСТ-КЕЙСЫ / ЧЕК-ЛИСТ / БАГ-РЕПОРТ]

Не переписывай все с нуля.

Сначала оцени мою работу и найди:

• пропущенные риски;
• дублирующиеся проверки;
• слабые Expected Results;
• неоднозначные проверки;
• отсутствующие negative cases;
• отсутствующие boundaries;
• неподтвержденные предположения.

Затем предложи только конкретные изменения и дополнительные проверки.

Объясняй, почему каждое изменение имеет смысл.

Это, пожалуй, один из наиболее полезных способов использовать AI в работе QA.

Не отдавать ему мышление полностью, а использовать как дополнительного ревьюера.

---

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

Запоминать двадцать шаблонов необязательно.

Большинство хороших QA-промптов можно построить по простой схеме:

Роль → Контекст → Задача → Ограничения → Формат результата.

Например:

Ты Senior Manual QA.

Мы тестируем интернет-магазин.

Пользователь может добавить в корзину максимум 10 единиц одного товара.

Составь проверки изменения количества товаров в корзине.

Учти позитивные, негативные и граничные сценарии.

Не придумывай требований, которых нет в описании.

Результат представь как таблицу: Test | Data | Expected Result | Priority.

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

И не бойтесь продолжать диалог с AI.

Если первый ответ оказался слишком поверхностным, можно написать:

Ты пропустил проверки, связанные с несколькими вкладками. Добавь только их.

Или:

Теперь проверь свой список и удали дублирующиеся сценарии.

Или:

Оставь только Critical и High Priority проверки, если на тестирование есть 30 минут.

Такой итеративный подход обычно эффективнее попытки написать один гигантский идеальный промпт с первого раза.

Чего не стоит делать при использовании AI в тестировании

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

Поэтому результат модели нельзя воспринимать как готовую истину.

Если ChatGPT сгенерировал 50 тест-кейсов, это не означает, что все 50 действительно нужны.

Хороший QA должен проверить:

Есть ли такой сценарий в требованиях?

Имеет ли проверка смысл для нашего продукта?

Не повторяет ли она другую проверку?

Правильный ли Expected Result?

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

То же относится к SQL-запросам, API-проверкам и баг-репортам.

AI помогает быстрее подготовить черновик.

Ответственность за качество проверки остается у тестировщика.

Современные подборки AI-практик для QA используют LLM именно для подобных задач: генерации и ревью тест-кейсов, баг-репортов, exploratory testing, API-проверок и другой тестовой документации.

Стоит ли указывать использование AI в резюме тестировщика

Само по себе:

Использую ChatGPT

вряд ли станет сильным пунктом резюме.

Гораздо интереснее показать конкретное применение инструмента.

Например:

Использовал AI-инструменты для подготовки тестовых данных, дополнительного review тестового покрытия и черновиков тестовой документации.

Или:

Использовал LLM для анализа требований и поиска дополнительных negative и edge-case сценариев с последующей ручной валидацией результатов.

Так работодатель хотя бы понимает, какую задачу вы способны решать с помощью инструмента.

Проверьте, видно ли ваши навыки из резюме

Можно знать Postman, SQL, DevTools, API, техники тест-дизайна и использовать AI в работе — но рекрутер об этом не узнает, если все эти навыки плохо представлены в резюме.

[Название сервиса] позволяет проанализировать резюме и посмотреть, какие важные навыки и части опыта в нем раскрыты слабо, что можно улучшить и насколько понятно резюме показывает вашу квалификацию.

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

А свое резюме тестировщика можете бесплатно проверить на updatecv.me