Содержание
Зачем QA-инженеру промпты?
Блок 1. Анализ требований
Промпт #1: GAP-анализ требований
Промпт #2: Матрица тест-покрытия
Блок 2. Тест-дизайн
Промпт #3: Boundary Value Analysis + бизнес-логика
Промпт #4: State Transition Testing
Блок 3. Работа с багами
Промпт #5: Root Cause Analysis (5 Why's)
Промпт #6: Баг-репорт по стандарту IEEE 829
Блок 4. Тестовые данные
Промпт #7: Генерация реалистичных тестовых данных
Промпт #8: Decision Table
Блок 5. Специализированное тестирование
Промпт #9: Чек-лист регрессионного тестирования
Промпт #10: Анализ логов из Kibana/ELK
Блок 6. Отчётность
Промпт #11: Executive Summary для стейкхолдеров
Промпт #12: Тренд-анализ метрик качества
Блок 7. Процессы и команда
Промпт #13: Agenda QA-ретроспективы
Промпт #14: Генерация Postman-коллекции для API
Блок 8. Стратегия
Промпт #15: Аудит и оптимизация QA-процесса
Как внедрять: 3-шаговый план
Частые ошибки и как их избежать
Итоги
Как использовать ChatGPT для решения реальных задач тестирования — с примерами результатов и практическими советами
Для кого: Manual/Automation QA, QA Lead, QA Analyst
Что внутри: Готовые промпты с примерами вывода и рекомендациями по использованию
Зачем QA-инженеру промпты?
За последнее время я протестировал множество промптов для GPT в реальных проектах, и часть из них показала стабильный результат, помогая команде решать типовые задачи быстрее и системнее. На практике это заметно ускоряет анализ требований, подготовку тест-кейсов и работу с багами, делая процесс более структурированным и прозрачным для менеджмента.
Эта статья — выжимка того, что реально работает. Правильные промпты помогают QA-инженеру не только автоматизировать рутинные задачи, но и сосредоточиться на стратегических аспектах тестирования.
Представьте обычный день QA: сотни требований, баг-репорты, матрицы тест-покрыти��, отчёты для менеджмента. Без промптов это ручная, однообразная работа. С грамотными шаблонами GPT можно ускорить анализ, выявлять пробелы в требованиях и даже генерировать реалистичные тестовые данные за минуты.
⚠️ Важное напоминание: ИИ может ошибаться и "галлюцинировать" — генерировать правдоподобный, но неверный контент. Всегда проверяйте результат критически, особенно для критичных задач.
Блок 1. Анализ требований
Промпт #1: GAP-анализ требований
Проблема: На старте проекта требования противоречивые, неполные или размытые.
Промпт:
Ты — senior QA-архитектор с 10-летним опытом. Проанализируй требования и найди: 1. Противоречия между бизнес-требованиями и технической спецификацией 2. Пропущенные сценарии (edge cases, error handling) 3. Неоднозначные формулировки, которые приведут к разной интерпретации 4. Риски для тестирования (шкала 1-5 по вероятности и влиянию) БИЗНЕС-ТРЕБОВАНИЯ: [вставить текст] ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ: [вставить текст] КОНТЕКСТ ПРОЕКТА: - Отрасль: [финтех/e-commerce/SaaS] - Критичность: [высокая/средняя/низкая] - Срок релиза: [дата] Выдай результат в виде: 1. Таблицы с gap'ами (что найдено | где | риск | последствия) 2. 5 конкретных вопросов для уточнения требований 3. Улучшенные формулировки для 3 самых критичных требований
Пример результата:
Gap | Локация | Риск | Последствия |
|---|---|---|---|
Не указано поведение при превышении лимита транзакций | БТ п.3.2 vs ТС п.4.1 | 5/5 | Блокировка пользователей в продакшене |
Противоречие в валидации email | БТ: обязательное поле / ТС: опциональное | 4/5 | Потеря лидов или UX-проблемы |
Польза: Сокращает время анализа и помогает выявить проблемы до начала разработки.
Промпт #2: Матрица тест-покрытия
Задача: Превратить требования в прозрачную стратегию тестирования.
Промпт:
Построй 5-уровневую матрицу тест-покрытия для модуля [название]: УРОВЕНЬ 1: Бизнес-требования → Тест-области УРОВЕНЬ 2: Тест-области → Типы тестирования (функциональное, регрессионное, интеграционное, E2E) УРОВЕНЬ 3: Типы тестирования → Конкретные тест-кейсы УРОВЕНЬ 4: Тест-кейсы → Приоритет автоматизации (высокий/средний/низкий + ROI) УРОВЕНЬ 5: Метрики покрытия (% требований, время выполнения, стоимость) ТРЕБОВАНИЯ: [вставить] Формат вывода: таблица с колонками [Требование | Тест-область | Тип | Кейс | Автоматизация | Приоритет | Время | ROI]
Польза: Делает покрытие понятным для менеджмента и помогает структурировать стратегию тестирования.
Блок 2. Тест-дизайн
Промпт #3: Boundary Value Analysis + бизнес-логика
Промпт:
Проанализируй функционал [описание] и выполни boundary value analysis. Учти: - Технические ограничения (типы данных, лимиты БД) - Бизнес-правила (например, минимальная сумма заказа $10) - Производительность на граничных значениях Формат вывода: | Параметр | Min-1 | Min | Min+1 | Nominal | Max-1 | Max | Max+1 | Ожидаемый результат | Риск |
Пример ввода: "Поле 'Возраст' для регистрации на платформе (доступ с 18 лет)"
Пример вывода:
Значение | Результат | Риск |
|---|---|---|
17 | Отказ в регистрации | Низкий |
18 | Успешная регистрация | Высокий (граница) |
19 | Успешная регистрация | Низкий |
150 | Ошибка валидации или регистрация | Средний (нет верхней границы в требованиях!) |
Польза: Помогает находить больше граничных кейсов и выявлять пропущенные ограничения в требованиях.
Промпт #4: State Transition Testing
Когда использовать: Сложные бизнес-процессы (заказы, платежи, воркфлоу).
Промпт:
Построй state-transition диаграмму для процесса [описание]: 1. Все возможные состояния объекта 2. Триггеры переходов 3. Запрещённые переходы 4. Deadlock states (состояния без выхода) 5. Unreachable states (недостижимые состояния) Выведи: - Таблицу переходов (Из состояния → Триггер → В состояние → Валидность) - Набор тест-кейсов для каждого перехода - Список рискованных переходов с обоснованием
Польза: Помогает найти логические баги в бизнес-процессах до начала разработки.
Блок 3. Работа с багами
Промпт #5: Root Cause Analysis (5 Why's)
Промпт:
Проведи RCA для дефекта: ОПИСАНИЕ БАГА: [вставить] Метод: 5 Why's по трём направлениям 1. Технические причины (код, архитектура, инфраструктура) 2. Процессные причины (review, testing, deployment) 3. Системные причины (коммуникация, документация, знания) Добавь: - Timeline событий, приведших к багу - Impact-матрицу (кто пострадал, какой ущерб) - 3-5 preventive actions (как не допустить в будущем) - Метрики эффективности этих действий
Польза: Переход от "починили симптом" к "устранили причину".
Промпт #6: Баг-репорт по стандарту IEEE 829
Промпт:
Создай баг-репорт по стандарту IEEE 829 для дефекта: [краткое описание бага] Включи секции: 1. Идентификация (ID, severity, priority, компонент) 2. Окружение (ОС, браузер, версия билда) 3. Шаги воспроизведения (нумерованный список) 4. Ожидаемый результат 5. Фактический результат 6. Доказательства (где приложить скриншоты/логи/видео) 7. Бизнес-влияние (сколько пользователей затронуто, потенциальные потери) 8. Дополнительная информация (workaround, связанные баги) Формат: Markdown для Jira/YouTrack
Польза: Сокращает количество уточняющих вопросов от разработчиков и ускоряет фикс багов.
Блок 4. Тестовые данные
Промпт #7: Генерация реалистичных тестовых данных
Промпт:
Сгенерируй тестовые данные в формате JSON для модуля [название]. Покрой сценарии: 1. Happy path (3-5 записей) 2. Boundary cases (граничные значения) 3. Negative cases (невалидные данные) 4. Security payloads (SQL injection, XSS) 5. Internationalization (кириллица, иероглифы, RTL-языки, эмодзи) 6. Performance dataset (1000+ записей для нагрузочного тестирования) Для каждого набора укажи: - Назначение (для какого тест-кейса) - Ожидаемый результат валидации Схема данных: [вставить JSON-схему или описание полей]
Пример результата: Готовый JSON-файл с комментариями для импорта в БД или API-тесты.
Польза: Экономит время на подготовку разнообразных тестовых данных для каждого модуля.
Промпт #8: Decision Table
Промпт:
Построй decision table для бизнес-правила: [описание правила, например: "Скидка на заказ зависит от суммы, статуса клиента и наличия промокода"] Выведи: 1. Таблицу условий и действий 2. Все возможные комбинации 3. Исключи логически невозможные варианты (с объяснением) 4. Сгенерируй тестовые данные для каждой валидной комбинации Формат: Markdown-таблица + JSON с тестовыми данными
Польза: Гарантирует полное покрытие комбинаторики сложных бизнес-правил.
Блок 5. Специализированное тестирование
Промпт #9: Чек-лист регрессионного тестирования
Промпт:
Создай чек-лист регрессионного тестирования для модуля [название] после изменения [описание изменения]: 1. ЗОНА ПРЯМОГО ВЛИЯНИЯ: - Какие функции изменились напрямую - Какие API/компоненты затронуты - Конкретные тест-кейсы для проверки 2. ЗОНА КОСВЕННОГО ВЛИЯНИЯ: - Связанные функции (shared components, dependencies) - Интеграционные точки - Тест-кейсы для smoke testing 3. КРИТИЧНЫЕ СЦЕНАРИИ: - Core user flows, которые нельзя сломать - Сценарии с высоким бизнес-риском - Приоритетные тест-кейсы 4. РИСКИ И EDGE CASES: - Что может сломаться неожиданно - Исторические проблемные зоны - Дополнительные проверки Контекст: - Описание изменения: [что меняли] - Архитектура: [монолит/микросервисы] - Критичность модуля: [высокая/средняя/низкая] Формат: Markdown чек-лист с чекбоксами, приоритетами и оценкой времени
Польза: Системный подход к регрессионному тестированию вместо хаотичного "прогоним основное".
Промпт #10: Анализ логов из Kibana/ELK
Когда использовать: Расследование багов, анализ production incidents, поиск паттернов ошибок.
Промпт:
Проанализируй логи из Kibana и найди проблемы: ЛОГИ: [вставить логи из Kibana — скопировать релевантные строки или JSON] КОНТЕКСТ: - Проблема: [описание инцидента или бага] - Период: [временной диапазон] - Затронутые компоненты: [сервисы/модули] - Симптомы: [что видят пользователи] ЗАДАЧИ: 1. Найди ошибки и warning'и (с группировкой по типу) 2. Построй timeline событий (что произошло и в какой последовательности) 3. Определи root cause (первопричина проблемы) 4. Найди корреляции (связанные события, паттерны) 5. Оцени impact (сколько запросов/пользователей затронуто) ВЫВЕДИ: - Таблицу с ошибками (timestamp | severity | сообщение | компонент | частота) - Реконструкцию сценария (что привело к проблеме) - Гипотезы о причинах (ранжированные по вероятности) - Рекомендации для воспроизведения бага - Предложения по мониторингу (какие алерты настроить) Формат: структурированный отчёт с выводами
Пример использования:
ЛОГИ: 2026-02-16 14:23:45 ERROR PaymentService - Transaction timeout: txn_12345 2026-02-16 14:23:45 WARN DatabasePool - Connection pool exhausted (50/50) 2026-02-16 14:23:46 ERROR PaymentService - Transaction timeout: txn_12346 2026-02-16 14:23:50 INFO DatabasePool - Pool recovered (45/50)
Пример вывода:
Время | Severity | Проблема | Частота |
|---|---|---|---|
14:23:45 | ERROR | Payment timeout | 15 случаев за минуту |
14:23:45 | WARN | DB pool exhausted | Продолжалось 5 секунд |
Root Cause: Исчерпание пула соединений к БД → таймауты платежей.
Польза: Быстрый анализ больших объёмов логов и выявление неочевидных связей между событиями.
⚠️ Важно: ИИ может неправильно интерпретировать специфичные для вашей системы коды ошибок. Всегда сверяйтесь с документацией.
Блок 6. Отчётность
Промпт #11: Executive Summary для стейкхолдеров
Промпт:
Сгенерируй отчёт о тестировании для стейкхолдеров за период [даты]: Структура: 1. EXECUTIVE SUMMARY (3-5 предложений для CEO) 2. КЛЮЧЕВЫЕ МЕТРИКИ: - Тест-кейсов выполнено: X/Y (%) - Найдено багов: critical/major/minor - Test pass rate: % - Отклонение от плана: дни 3. КРИТИЧЕСКИЕ БАГИ (топ-3 с бизнес-влиянием) 4. РИСКИ РЕЛИЗА (вероятность × влияние) 5. РЕКОМЕНДАЦИИ (GO/NO-GO с обоснованием) 6. LESSONS LEARNED (что улучшить в следующем спринте) Исходные данные: [вставить статистику из Jira/TestRail] Tone: деловой, без технического жаргона
Польза: Отчёт, который менеджмент читает от начала до конца и принимает решения на его основе.
Промпт #12: Тренд-анализ метрик качества
Промпт:
Проанализируй метрики качества за [период]: Данные: [вставить CSV/таблицу с метриками по неделям: bug count, severity distribution, fix time, regression rate] Выполни: 1. Тренд-анализ (растёт/падает/стабильно + корреляции) 2. Benchmarking (сравнение с прошлым кварталом и industry standards) 3. Root Cause для негативных трендов 4. Прогноз на следующий месяц (оптимистичный/реалистичный/пессимистичный) 5. Топ-3 рекомендации для улучшения Визуализация: опиши, какие графики построить
Польза: Превращает сухую статистику в actionable insights для улучшения процессов.
Блок 7. Процессы и команда
Промпт #13: Agenda QA-ретроспективы
Промпт:
Подготовь повестку QA-ретроспективы на 90 минут: Формат: Start/Stop/Continue + action items Структура: 1. Check-in (10 мин) — ледокол 2. Review previous action items (15 мин) 3. What went well (20 мин) — сбор фактов 4. What didn't go well (20 мин) — без blame 5. Идеи для улучшения (15 мин) — brainstorming 6. Голосование и приоритизация (5 мин) 7. Action items (10 мин) — кто, что, когда 8. Closing (5 мин) Добавь: - Ожидаемые результаты каждой секции - Кто фасилитирует - Шаблон для фиксации action items (в Notion/Miro)
Польза: Ретроспективы становятся продуктивными встречами с конкретными результатами.
Промпт #14: Генерация Postman-коллекции для API
Когда использовать: Начало работы с новым API, подготовка тестовых запросов, документация для команды.
Промпт:
Создай Postman-коллекцию для тестирования API [название]: API СПЕЦИФИКАЦИЯ: [вставить Swagger/OpenAPI документацию или описание эндпоинтов] ТРЕБОВАНИЯ: 1. Базовые CRUD-операции для основных ресурсов 2. Позитивные и негативные сценарии для каждого эндпоинта 3. Граничные случаи (пустые поля, превышение лимитов, некорректные форматы) 4. Тесты аутентификации/авторизации (если требуется) 5. Переменные окружения (base_url, tokens, test_data) СТРУКТУРА КОЛЛЕКЦИИ: - Папки по ресурсам (Users, Orders, Products и т.д.) - Нейминг запросов: [METHOD] [Endpoint] - [Scenario] Пример: POST /users - Create user with valid data - Pre-request scripts (если нужна подготовка данных) - Tests scripts с assertions: * Status code проверки * Response schema validation * Response time < Xms * Проверка ключевых полей ВЫВЕДИ: 1. JSON коллекции в формате Postman Collection v2.1 2. Описание каждого запроса (что тестирует) 3. Примеры тестовых данных в body 4. Environment variables (шаблон) 5. Инструкцию по запуску коллекции Контекст: - Тип API: [REST/GraphQL] - Аутентификация: [Bearer token/API key/OAuth] - Base URL: [адрес]
Пример вывода (фрагмент):
{ "info": { "name": "User API Tests", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }, "item": [ { "name": "Users", "item": [ { "name": "POST /users - Create user with valid data", "request": { "method": "POST", "url": "{{base_url}}/users", "body": { "mode": "raw", "raw": "{\n \"email\": \"test@example.com\",\n \"name\": \"John Doe\"\n}" } }, "event": [ { "listen": "test", "script": { "exec": [ "pm.test('Status code is 201', function() {", " pm.response.to.have.status(201);", "});", "pm.test('Response has user id', function() {", " pm.expect(pm.response.json()).to.have.property('id');", "});" ] } } ] }, { "name": "POST /users - Create user with invalid email", "request": { "method": "POST", "url": "{{base_url}}/users", "body": { "mode": "raw", "raw": "{\n \"email\": \"invalid-email\",\n \"name\": \"John Doe\"\n}" } }, "event": [ { "listen": "test", "script": { "exec": [ "pm.test('Status code is 400', function() {", " pm.response.to.have.status(400);", "});", "pm.test('Error message contains email validation', function() {", " pm.expect(pm.response.json().error).to.include('email');", "});" ] } } ] } ] } ] }
Environment variables шаблон:
{ "name": "Test Environment", "values": [ {"key": "base_url", "value": "https://api.test.example.com"}, {"key": "api_token", "value": "your_test_token_here"}, {"key": "user_id", "value": ""} ] }
Польза: Готовая коллекция запросов экономит часы ручной подготовки и стандартизирует API-тестирование в команде.
⚠️ Важно: Проверьте, что assertions соответствуют реальному поведению вашего API. ИИ может сгенерировать ожидания на основе общих практик, а не вашей специфики.
Блок 8. Стратегия
Промпт #15: Аудит и оптимизация QA-процесса
Промпт:
Проанализируй текущий QA-процесс и предложи улучшения: ТЕКУЩЕЕ СОСТОЯНИЕ: [описание: как проходит тестирование, какие инструменты, какие боли] Выполни анализ по категориям: 1. QUICK WINS (внедрение за неделю, результат сразу) 2. MEDIUM TERM (1-3 месяца, требуют ресурсов) 3. LONG TERM (стратегические изменения на 6-12 месяцев) Для каждого улучшения укажи: - Проблема, которую решает - Требуемые ресурсы (время, люди, бюджет) - Ожидаемый эффект (метрики до/после) - Риски внедрения Добавь: - Roadmap внедрения (timeline с вехами) - KPI для отслеживания эффекта - Коммуникационный план (как донести до команды)
Польза: Системная трансформация QA-процессов вместо хаотичных улучшений.
Как внедрять: 3-шаговый план
Шаг 1: Выберите больное место (неделя 1)
Не пытайтесь использовать все промпты сразу. Выберите 1-2 самых болезненных процесса:
Тратите много времени на анализ требований? → Промпты #1-2
Баги возвращаются из-за неполных репортов? → Промпты #5-6
Менеджмент не понимает статус тестирования? → Промпты #11-12
Шаг 2: Адаптируйте под проект (неделя 2)
Возьмите базовый промпт из статьи
Добавьте специфику вашего домена (финтех/e-commerce/SaaS)
Укажите форматы вывода, которые приняты в команде
Протестируйте на реальной задаче
Шаг 3: Масштабируйте (неделя 3+)
Сохраните промпт в Notion/Confluence как шаблон
Проведите демо для команды (покажите результат)
Соберите обратную связь и улучшите
Добавьте в definition of done: "Для задач типа X использовать промпт Y"
⚠️ Частые ошибки и как их избежать
❌ Ошибка #1: Слишком общий контекст
Плохо: "Проанализируй требования"
Хорошо: "Проанализируй требования для модуля оплаты в финтех-приложении с PCI DSS compliance"
❌ Ошибка #2: Не проверять результат
Почему опасно: ИИ может "галлюцинировать" — генерировать правдоподобную, но неверную информацию.
Как проверять:
Сравните с вашими знаниями домена
Для критичных задач (security, compliance) — обязательная ручная проверка
Используйте результат как драфт, а не финальную версию
Перепроверяйте факты, особенно цифры и стандарты
❌ Ошибка #3: Не адаптировать под проект
Промпты из статьи — это шаблоны. Вам нужно:
Добавить терминологию вашей компании
Указать специфику технологий
Встроить в существующие процессы
❌ Ошибка #4: Слепо доверять выводам по security
Важно: Для security-тестирования результаты ИИ — только отправная точка. Всегда:
Проверяйте рекомендации по OWASP/CWE
Консультируйтесь с security-специалистами
Для продакшена — обязательный профессиональный пентест
Итоги
Каждый проект уникален и неповторим. У вас своя специфика бизнеса, своя архитектура, свои процессы и свои вызовы. Промпты из этой статьи — это не готовые решения "из коробки", а скорее отправные точки, которые нужно адаптировать под ваш контекст.
Надеюсь, этот материал окажется вам полезным и поможет решать задачи на вашем проекте быстрее и системнее. Возможно, какие-то промпты вы возьмёте целиком, а что-то переработаете под себя — и это абсолютно нормально.
⚠️ Финальное напоминание: ИИ — это мощный помощник, но не замена критическому мышлению. Всегда проверяйте результаты, особенно для критичных задач. Используйте промпты как ускоритель работы, а не как безусловный источник истины.
