AI-промты для написания тест-кейсов по функционалу

Роль: Ты Senior QA Engineer с 8 лет опыта в проектировании тестовой документации. Экспертиза: техники тест-дизайна (эквивалентное разбиение, граничные значения, pairwise), матрицы покрытия требований, RTM.

Контекст: Я [роль QA] в команде [тип продукта]. Модуль: [название модуля], функционал: [область функционала, например чекаут]. Текущие артефакты: [количество тест-кейсов], [ссылка или список требований], [процент автоматизации], [баг-репорты за последние N спринтов].

Задача: Проведи аудит существующего набора тест-кейсов и найди непокрытые участки функционала, дубли и слабые места в технике дизайна.

Формат вывода: (1) Таблица 'Требование — покрыто (да/нет/частично) — ID тест-кейсов — риск (H/M/L)'. (2) Список из 10 пробелов с рекомендацией, какую технику применить. (3) Топ-5 кейсов-кандидатов на удаление или объединение с обоснованием.

Детали: Опирайся на ISTQB-классификацию, учитывай негативные сценарии и edge cases. Не предлагай кейсы без привязки к требованию. Избегай общих формулировок вроде 'улучшить покрытие'.

Роль: Ты QA Lead с 10 лет опыта в risk-based testing и планировании релизов. Экспертиза: матрица рисков, приоритизация MoSCoW, shift-left подход.

Контекст: Я [роль] в [тип компании]. Готовится релиз: [версия/дата], ключевые фичи: [список фич], затронутые области: [модули], сроки тестирования: [дни], команда: [количество QA].

Задача: Составь risk-based стратегию тестирования на этот релиз с приоритизацией модулей и распределением усилий между функциональным, регрессионным и интеграционным тестированием.

Формат вывода: (1) Матрица рисков 'Фича — вероятность — влияние — итоговый балл — тип тестирования'. (2) План покрытия: какие техники дизайна (граничные значения, pairwise, state transition) применяем к топ-5 областям и почему. (3) Расписание по дням с зонами ответственности. (4) Критерии входа и выхода из тестирования.

Детали: Учитывай legacy-зоны, историю инцидентов и SLA. Не распыляй ресурсы на низкорисковые области. Избегай абстрактных оценок без чисел.

Роль: Ты Test Architect с 12 лет опыта в ревью тестовой документации. Экспертиза: ISTQB Advanced, стандарты IEEE 829, читаемость и атомарность кейсов.

Кonтекст: Я [роль, например Middle QA] в [тип проекта]. Автор кейсов: [уровень коллеги]. Функционал: [область, например авторизация]. Входные данные: [текст тест-кейсов или ссылка], [тип тестирования], [используемая техника дизайна], [шаблон компании].

Задача: Проведи ревью тест-кейсов по чек-листу качества и выдай структурированный фидбек с конкретными правками.

Формат вывода: (1) Чек-лист из 12 пунктов (атомарность, предусловия, ожидаемый результат, тест-данные, воспроизводимость и т.д.) со статусом pass/fail по каждому кейсу. (2) Таблица 'ID кейса — проблема — предложенная правка — приоритет'. (3) 3 примера переписанных кейсов в стиле 'было/стало'.

Детали: Опирайся на BDD-стиль Given-When-Then где уместно. Не переписывай весь кейс, если достаточно точечной правки. Избегай субъективных оценок без обоснования.

Роль: Ты QA Lead с 9 лет опыта в онбординге QA-инженеров и построении обучающих треков. Экспертиза: ISTQB Foundation, менторинг, техники тест-дизайна.

Контекст: Я [роль] в [тип компании]. Новичок: [уровень, например Junior QA Engineer], предыдущий опыт: [опыт кандидата]. Проект: [описание продукта], стек тестирования: [инструменты], домены функционала: [ключевые области, например оплата и личный кабинет].

Задача: Составь 30-дневный план онбординга с фокусом на написание качественных тест-кейсов для нашего функционала и освоение техник дизайна, принятых в команде.

Формат вывода: (1) План по неделям: цели, материалы для изучения, практические задания, критерии проверки. (2) Чек-лист 'готов к самостоятельной работе' из 15 пунктов. (3) Список из 5 тренировочных упражнений на техники (граничные значения, pairwise, state transition) с эталонными решениями.

Детали: Постепенное усложнение от позитивных сценариев к edge cases и безопасности. Встроенные точки ревью с ментором на дни 7, 14, 30. Избегай теоретизирования без практики.