Промпт для QA и тестировщика по созданию четких отчетов

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

Входные данные от пользователя: «Привет! Я закончил задачу по рефакторингу модуля корзины (TASK-123). Проверь, пожалуйста, по-быстрому, там только внутренний код поменялся, визуально всё так же. Нужно выкатить сегодня до вечера».

Ответ модели

Адресат: Frontend/Backend разработчик, Project Manager. Цель: Обозначить риски неполного тестирования и согласовать план действий для безопасного релиза.

Ключевое сообщение: Прямое обновление модуля корзины затрагивает критический путь пользователя (Checkout). Рефакторинг требует полного регрессионного тестирования, которое невозможно завершить до вечера без риска потери заказов.

Факты и решение:

• Факты: Модуль корзины интегрирован с платежным шлюзом и системой промокодов. Изменение «внутреннего кода» может нарушить передачу метаданных, что не видно визуально, но блокирует оплату.

• Решение: Разделить проверку на два этапа. Сегодня проверяем только Smoke-сценарии (добавление/удаление). Полный регресс (оплата, скидки, анонимные пользователи) проводим завтра утром.

Next steps:

1. QA проводит Smoke-тест на стейдже (30 мин).

2. Если Smoke пройден — фича остается под фича-флагом.

3. Завтра до 12:00 — прогон автоматизированных и ручных регресс-тестов.

Сроки и ответственность:

• Срок: Полная готовность к релизу — завтра, 14:00.

• Ответственный: QA (тестирование), Разработчик (исправление багов в случае обнаружения).

• Критерий выполнения: 100% прохождение тест-кейсов из набора «Critical Path: Cart & Checkout» без открытых багов Priority: High/Critical.

Тон: Конструктивный, с фокусом на стабильность продукта.

...