15 промптов, которые заставят ChatGPT работать вместо QA-инженера

Зачем QA-инженеру промпты? (Спойлер: чтобы не делать рутину)

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

А мог бы просто скопировать промпт в ChatGPT и получить готовый анализ за 30 секунд.

Промпты для QA - это не "магия", а конкретные инструкции, которые превращают ChatGPT из болтливого собеседника в рабочего инструмента. Как отвертка или Postman. Только умнее.

Часть 1: Анализ требований (где все начинается и где все ломается)

Плохие требования - причина 80% багов. И 100% нервных срывов QA. Эти промпты помогают вытащить проблемы до того, как они станут проблемами.

1 Промпт для декомпозиции пользовательских историй

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

Разложи пользовательскую историю на конкретные функциональные требования и acceptance criteria.

Формат ответа:
1. Основная функциональность
2. Предусловия
3. Основной поток
4. Альтернативные потоки
5. Постусловия
6. Критерии приемки (Gherkin-формат)

История: [вставь текст пользовательской истории]

2 Поиск противоречий в документации

Когда техлид говорит "все в документации", а в документации три разных ответа на один вопрос.

Проанализируй техническую документацию на предмет противоречий, неоднозначностей и missing requirements.

Документация:
"""
[вставь текст документации или требования]
"""

Найди:
1. Прямые противоречия (разные значения для одного поля)
2. Неоднозначные формулировки
3. Отсутствующие требования (что должно быть, но не описано)
4. Предположения, которые могут быть неверными

3 Генерация вопросов к аналитику

Вместо "у меня есть вопросы" - конкретный список из 15 пунктов, которые закрывают все слепые зоны.

Сгенерируй список уточняющих вопросов к аналитику/продукт-менеджеру на основе требований.

Требования:
"""
[вставь требования]
"""

Сфокусируйся на:
- Edge cases, которые не покрыты
- Бизнес-логике в спорных ситуациях
- Ограничениях производительности
- Совместимости с существующей системой
- Данных по умолчанию и валидации

Часть 2: Тест-дизайн (когда нужно придумать 100 способов сломать то, что только что построили)

Здесь ChatGPT заменяет мозговой штурм. И делает это без усталости и сарказма.

4 Генерация тест-кейсов по классам эквивалентности

Классика, которую все проходят на курсах вроде Ручное тестирование (Manual QA), но редко используют системно.

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

Функция/фича: [опиши что тестируем]
Поля/параметры: [список полей с типами данных]
Ограничения: [валидационные правила, если есть]

Формат:
- Класс эквивалентности
- Представители класса (валидные/невалидные)
- Граничные значения
- Ожидаемый результат

5 Создание матрицы принятия решений

Для сложной бизнес-логики, где 5 условий дают 32 возможных исхода.

Создай матрицу принятия решений (decision table) для бизнес-правил.

Правила:
"""
[опиши бизнес-правила и условия]
"""

Включи:
- Все возможные комбинации условий
- Ожидаемые действия/результаты
- Приоритет правил при конфликтах
- Тест-кейсы для каждой строки таблицы

6 Тест-кейсы для API (Swagger/OpenAPI)

Дал ChatGPT спецификацию - получил готовые тесты для Postman.

Сгенерируй тест-кейсы для REST API на основе OpenAPI спецификации.

Спецификация:
"""
[вставь YAML/JSON спецификации]
"""

Для каждого endpoint создай:
1. Happy path тесты
2. Негативные тесты (невалидные данные, отсутствующие поля)
3. Тесты авторизации/аутентификации
4. Тесты на валидацию схемы ответа
5. Примеры тестовых данных

Формат: таблица с полями: Method, URL, Request Body, Expected Status, Expected Response

7 Сценарии тестирования состояния и перехода

Когда фича имеет 10 состояний и 20 переходов между ними.

Создай диаграмму состояний и переходов (state transition diagram) и тест-кейсы для каждого перехода.

Система/объект: [что тестируем]
Состояния: [список возможных состояний]
События/действия: [что вызывает переходы]
Бизнес-правила переходов: [ограничения]

Выведи:
1. Диаграмму в текстовом формате
2. Матрицу переходов
3. Тест-кейсы для валидных переходов
4. Тест-кейсы для невалидных переходов (должны быть заблокированы)

Если хочешь пойти дальше и автоматизировать не только дизайн, но и выполнение тестов, посмотри как строить многоуровневые промпты для автотестов. Разница между junior и senior подходом - в деталях.

Часть 3: Баг-репорты (искусство описать проблему так, чтобы разработчик не захотел тебя убить)

Хороший баг-репорт - это когда разработчик говорит "спасибо" вместо "что это вообще такое?".

8 Структурирование сырых наблюдений в баг-репорт

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

Преобразуй сырые наблюдения в структурированный баг-репорт.

Формат:
- Заголовок (кратко, что сломалось)
- Шаги воспроизведения (пошагово, чтобы любой мог повторить)
- Фактический результат (что видишь)
- Ожидаемый результат (что должно быть)
- Окружение (браузер, ОС, версия приложения)
- Приоритет/серьезность
- Логи/скриншоты (если есть)
- Дополнительный контекст

Наблюдения:
"""
[вставь свои заметки]
"""

9 Анализ логов и поиск root cause

Когда в логах 1000 строк, а нужна одна.

Проанализируй логи приложения и найди возможные причины ошибки.

Логи:
"""
[вставь логи]
"""

Ошибка/симптом: [опиши что происходит]

Проанализируй:
1. Временную последовательность событий
2. Сообщения об ошибках и их коды
3. Паттерны (повторяющиеся ошибки)
4. Корреляцию с действиями пользователя
5. Предположительную root cause
6. Рекомендации по дальнейшему исследованию

10 Воспроизведение бага по описанию пользователя

Пользователь написал "у меня ничего не работает". Твоя задача понять что именно.

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

Описание пользователя:
"""
[вставь описание проблемы]
"""

Система: [название системы/приложения]

Выведи:
1. Интерпретация проблемы (перевод с "пользовательского" на "технический")
2. Список возможных причин (от наиболее вероятных к наименее)
3. Шаги для воспроизведения/проверки каждой гипотезы
4. Вопросы, которые нужно задать пользователю для уточнения

Часть 4: Автоматизация и регрессия (где промпты экономят реальные деньги)

Здесь каждый промпт - это сэкономленные человеко-часы. Иногда - человеко-дни.

11 Генерация скриптов для тестовых данных

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

Сгенерируй SQL/Python скрипт для создания тестовых данных.

Требования к данным:
- Таблицы/сущности: [список]
- Количество записей для каждой
- Связи между сущностями
- Бизнес-правила (валидные комбинации)
- Необходимое разнообразие данных
- Опционально: шаблоны для конкретных тест-кейсов

Формат вывода: готовый к выполнению скрипт с комментариями

12 Чек-лист регрессионного тестирования

Перед релизом нужно проверить 50 критичных функций. Что точно не сломали?

Создай чек-лист для регрессионного тестирования на основе изменений в релизе.

Изменения в релизе:
"""
[опиши что поменялось: новые фичи, исправления багов, изменения API]
"""

Существующая система: [краткое описание основных модулей]

Создай чек-лист который включает:
1. Прямо затронутые функции (must test)
2. Косвенно затронутые функции (should test)
3. Критичный бизнес-функционал (smoke test)
4. Интеграционные точки
5. Предыдущие проблемные области

Для каждого пункта укажи:
- Что проверять
- Как проверять (ручное/авто)
- Критерий успеха
- Приоритет проверки

13 Конвертация ручных тестов в автотесты

У тебя есть 100 ручных тест-кейсов. Хочешь их автоматизировать, но писать код лень.

Конвертируй ручные тест-кейсы в код автотестов на [Python/pytest или JavaScript/Jest].

Тест-кейсы:
"""
[вставь описание ручных тестов]
"""

Технический контекст:
- Язык программирования: [Python/JavaScript/etc]
- Фреймворк: [pytest/Jest/etc]
- Библиотеки: [Selenium/Playwright/Cypress/etc]
- Паттерны проекта: [как организованы тесты]

Требования к коду:
- Использовать Page Object/Component паттерн
- Добавить setup/teardown
- Включить assertions с понятными сообщениями
- Добавить логирование
- Сделать код поддерживаемым

14 Анализ покрытия тестами

Есть отчёт о покрытии. Что на самом деле означает "87% покрытия"?

Проанализируй отчёт о покрытии тестами и предложи план по улучшению.

Отчёт о покрытии:
"""
[вставь данные о покрытии: какие модули/функции покрыты, какие нет]
"""

Контекст:
- Критичные бизнес-модули: [список]
- Часто меняющийся код: [список]
- Исторически проблемные области: [список]

Проанализируй:
1. Где coverage ниже порогового значения
2. Какие непокрытые участки критичны для бизнеса
3. Паттерны в непокрытом коде (например, все error handlers)
4. Рекомендации по приоритизации
5. Оценка усилий для достижения целевого покрытия

15 Планирование нагрузочного тестирования

Нужно понять, выдержит ли система 10 000 пользователей. С чего начать?

Создай план нагрузочного тестирования для веб-приложения/API.

Система:
- Тип: [веб-приложение/API/микросервис]
- Ожидаемая нагрузка: [пиковое количество пользователей/RPS]
- Критичные сценарии: [что чаще всего используют]
- SLA требования: [максимальное время ответа, допустимые ошибки]

План должен включать:
1. Цели тестирования (что измеряем)
2. Тестовые сценарии (user journeys)
3. Профиль нагрузки (ramp-up, пик, ramp-down)
4. Метрики для сбора
5. Критерии успеха/провала
6. Инструменты (JMeter/k6/Locust)
7. Риски и ограничения

Если тебя интересует полная автоматизация QA процесса, посмотри архитектуру автономного ИИ-агента для тестирования. Это следующий уровень после промптов.

Как заставить это работать на практике (а не просто сохранить в закладках)

15 промптов - это много. Начинай с одного-двух, которые решают твою самую болезненную проблему прямо сейчас.

Самый частый вопрос: "А что если ChatGPT сгенерирует ерунду?"

Ответ: проверяй. Всегда. ChatGPT - помощник, а не замена. Он может пропустить edge case, не знать про внутренние ограничения системы, предложить неоптимальное решение.

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

Что дальше? (Когда промптов станет мало)

Эти 15 промптов закрывают 80% рутинных задач. Но есть ещё 20% - сложные сценарии, интеграционное тестирование, безопасность, производительность.

Дальше два пути:

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

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

А сложные повороты, обгоны и парковка - всё ещё за тобой.

Начни с одного промпта сегодня. Просто выбери самую нудную задачу и попробуй делегировать её ChatGPT. Результат может удивить.