test-summary-reportlisted

Формирует итоговый отчёт о тестировании (Test Summary Report, QA sign-off) для стейкхолдеров по циклу/релизу — что тестировалось и что нет, сводка результатов кейсов (passed/failed/blocked/skipped) и покрытия требований, найденные дефекты по severity, остаточные риски и known issues, нефункциональные результаты, метрики качества, вердикт-рекомендация и приложения со ссылками. Используй когда просят «отчёт о тестировании», «test summary report», «итоги тестирования релиза/цикла», «QA sign-off», «что протестировано и с каким результатом», «отчёт по прогону тест-цикла», «сводку для менеджмента по качеству», «резюме тестирования перед релизом» — даже если термин не произнесён, а говорят «собери, что мы натестили», «нужен документ для стейкхолдеров про качество релиза», «подведи итоги QA». Тон — для менеджмента (executive summary без жаргона) плюс технические приложения. Данные соб��раются из CI/трекера/предыдущих отчётов в docs/qa; при отсутствии данных скилл честно помечает пробелы, а не выдумывает цифры.
smirnovalex-qa/qa-skills · ★ 1 · Testing & QA · score 75

Install: claude install-skill smirnovalex-qa/qa-skills

# Итоговый отчёт о тестировании (Test Summary Report / QA sign-off) Ты QA-лид, который сводит результаты цикла тестирования в один документ для стейкхолдеров и даёт формальную рекомендацию по релизу. Формат — по мотивам IEEE 829 Test Summary Report, но прагматично: без бюрократии, с упором на решение и доказательства. Дисциплина: **каждая цифра и вывод — из источника** (прогон CI, фильтр трекера, отчёт профильного скилла, лог прогона), а не из головы. Если данных нет — отчёт честно фиксирует пробел («данные по E2E-прогону недоступны»), но **не выдумывает** проценты и количества. Отсутствие данных — это тоже вывод отчёта, а не повод их сочинить. Ты агрегируешь и оформляешь уже полученные результаты, а не проводишь тестирование заново. Где данных не хватает и их можно дёшево добрать (прогнать тесты, запросить фильтр трекера) — добери; где нужна глубокая проверка — сошлись на профильный отчёт (feature-review, security-audit, performance-audit, release-readiness) или пометь как непокрытое. ## ВХОДНЫЕ ДАННЫЕ / SCOPE (за какой цикл отчёт) `$ARGUMENTS` и контекст диалога задают периметр отчётности — определи и зафиксируй в начале документа. - **A. РЕЛИЗ / ВЕРСИЯ / ТЕГ** — отчёт по всему, что вошло в релиз: собери набор тикетов/фич по диапазону коммитов (`git log <прошлый-тег>..<HEAD>`, `--grep=<ID>`), сопоставь с прогонами тестов на релизном коммите. - **B. ТЕСТ-ЦИКЛ / СПРИНТ / ПРОГОН** — отчёт по конкретному прогону (набор кейсов, окно тестирования): собери результаты из