Илья Немыгин пишет:

4 промта, которые ты можешь использовать

Правила: • Больше контекста — меньше бреда. • Пример лучше инструкции. • Проверяй. Ошибётся уверенно. • Не вставляй реальные данные и секреты.

❗️Никаких персональных данных и секретной информации в чат не отправляем

1. Требования

Ты — senior QA-архитектор с 10-летним опытом.

Проанализируй требования и найди: 1. Противоречия между бизнес-требованиями и технической спецификацией 2. Пропущенные сценарии (edge cases, error handling) 3. Неоднозначные формулировки, которые приведут к разной интерпретации 4. Риски для тестирования (шкала 1-5 по вероятности и влиянию)

БИЗНЕС-ТРЕБОВАНИЯ: [вставить текст]

ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ: [вставить текст]

КОНТЕКСТ ПРОЕКТА: - Отрасль: [финтех/e-commerce/SaaS] - Критичность: [высокая/средняя/низкая] - Срок релиза: [дата]

Выдай результат в виде: 1. Таблицы с gap'ами (что найдено | где | риск | последствия) 2. 5 конкретных вопросов для уточнения требований 3. Улучшенные формулировки для 3 самых критичных требований

2. Тест-кейсы

Роль: Ты – Senior QA Engineer

Задача: Сгенерируй полный набор тест-кейсов для следующих требований

Правила: - Не выдумывай никакой дополнительной функциональности - Если для написания теста не хватает информации, напиши: 'Для написания теста не хватает информации: [что именно не хватает]' - Каждый тест-кейс должен иметь уникальный ID и ссылаться на номер пункта требований

Контекст: [Вставить текст требований]

Ограничения: - Каждый тест-кейс должен трассироваться к конкретному критерию приёмки - Шаги должны быть атомарными и воспроизводимыми - Не генерируй тесты для неявной функциональности

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

Сгенерируй тестовые данные в формате 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-схему или описание полей]

4. Баг-репорт

Роль: Ты — QA-инженер, анализирующий логи для составления баг-репорта

Задача: На основе следующих данных сгенерируй полный баг-репорт

Данные для анализа: - Шаги воспроизведения: [Описать шаги] - Ожидаемый результат: [Описать ожидаемое] - Фактический результат: [Описать фактический] - Среда: [Описать окружение] - Логи/Скриншоты: [Описать или вставить фрагменты]

Ограничения: - Различай факты (наблюдаемое поведение) и гипотезы (предполагаемые причины) - Укажи уровень уверенности для каждой гипотезы (Высокий/Средний/Низкий) - Перечисли недостающую информацию, необходимую для подтверждения

Формат вывода: - Summary: <Краткое описание проблемы> - Environment: <Из данных> - Steps to Reproduce: <Из данных> - Actual Result: <Из данных> - Expected Result: <Из данных> - Evidence: <Краткое описание логов/скриншотов> - Severity: - Priority: - Suspected area: <Предположение об участке кода/сервиса> - Notes for dev: <Список предположений или гипотез>

Если для заполнения какого-либо поля не хватает данных, напиши '[НЕ ХВАТАЕТ ДАННЫХ: описание]'.