# Ru > Формирует итоговый отчёт о тестировании (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; при отсутствии данных скилл честно помечает пробелы, а не выдумывает цифры. - Skill: `smirnovalex-qa/ru-23` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-23` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-23/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-23 --- # Итоговый отчёт о тестировании (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 <прошлый-тег>..`, `--grep=`), сопоставь с прогонами тестов на релизном коммите. - **B. ТЕСТ-ЦИКЛ / СПРИНТ / ПРОГОН** — отчёт по конкретному прогону (набор кейсов, окно тестирования): собери результаты из CI/трекера за этот период. - **C. ФИЧА / МОДУЛЬ** — отчёт по тестированию одной области; периметр = её файлы/эндпоинты/экраны + смежное, что проверялось на регрессию. Источники данных (собери, что доступно, зафиксируй, откуда взято): - **CI/пайплайн** — прогоны unit/integration/E2E/API, отчёты покрытия, артефакты (определи CI по конфигам: GitHub Actions/GitLab CI/Jenkins/…). - **Issue/трекер** (Jira/YouTrack/GitHub Issues/Linear) — дефекты по периметру: фильтр по severity, статусу (open/closed), метке релиза. Через доступную интеграцию (MCP-инструмент, если подключён); если доступа нет — запроси у пользователя выгрузку/фильтр, не додумывай числа. - **Предыдущие отчёты** в `docs/qa/` и `docs/bugs/` — отчёты аудитов безопасности/производительности/доступности, отчёт release-readiness, тест-планы/чек-листы, из которых берётся статус нефункциональных проверок. - **Логи прогонов тестов** — если можешь запустить сам, запусти и приложи вывод. Если периметр не определить (непонятно, за какой релиз/цикл отчёт) — остановись и уточни. Если определён периметр, но нет данных о прогоне — это не повод отказаться: составь отчёт с явными пробелами в разделах, где данных нет. ## КЛЮЧЕВОЙ ПРИНЦИП: ОТЧЁТ ФИКСИРУЕТ ФАКТ, А НЕ ЖЕЛАЕМОЕ - Не пиши «все тесты пройдены», если видел только unit; напиши, какие уровни прогонялись, а какие — нет. - Не превращай «0 найденных багов» в «багов нет»: 0 найденных при непроведённом тестировании области — это непокрытие, а не качество. Разделяй «проверено и чисто» от «не проверено». - Числа сверяй с источником и указывай источник рядом. «12 из 47 кейсов упало (прогон CI #338)» — да; «в основном всё зелёное» — нет. - Вердикт должен следовать из данных отчёта, а не из оптимизма. Открытый Critical в периметре несовместим с «готово к релизу». ## СТРУКТУРА ОТЧЁТА (по мотивам IEEE 829, прагматично) Собери документ из следующих разделов. Тон верхних разделов — для менеджмента (executive summary без технического жаргона); технические детали и логи — в приложениях. 1. **Обзор / что тестировалось (scope)** - Объекты тестирования: сервисы/модули/экраны/версии, вошедшие в цикл. - Что покрывалось: типы тестирования (функциональное, регрессия, интеграционное, E2E, API, нефункциональное — что именно проводилось). - Окружение(я), на которых тестировали (dev/staging/…), сборка/версия. - Период/цикл, участники (если релевантно). 2. **Что НЕ тестировалось и почему** - Области, сознательно оставленные за периметром (нет доступа к прод, нет окружения, headless, не хватило времени, отложено на следующий цикл). - Это критично: без этого раздела «нет находок» ложно читается как «всё чисто». 3. **Сводка результатов** - Кейсы: passed / failed / blocked / skipped — числами и в разбивке по типам/ модулям (таблица). Каждая цифра — со ссылкой на прогон/источник. - Покрытие требований: сколько acceptance criteria/требований проверено, сколько закрыто, сколько не покрыто (сопоставь с requirements/тикетами). - Разбивка по тестовой пирамиде: что дал unit / integration / E2E / API- контракт, если данные есть. 4. **Найденные дефекты** - Сводка по severity (Critical/High/Medium/Low) и статусу (open/closed) — таблица с числами и ссылками на тикеты. - Критичные/блокирующие — перечисли отдельно: что именно, что блокирует, статус фикса. - Тренд, если есть данные предыдущего цикла (стало лучше/хуже). 5. **Оценка качества и рисков** - Остаточные риски: что может сломаться на проде, что покрыто слабо. - Known issues — известные проблемы, идущие в релиз осознанно, с тикетами и обоснованием (почему допустимо выпускать с ними). - Оценка стабильности/зрелости релиза в целом. 6. **Нефункциональные результаты** (если проводились) - Производительность (из performance-audit/нагрузочных прогонов): в пределах SLA или есть деградации. - Безопасность (из security-audit): статус, открытые находки по severity. - Доступность (a11y/WCAG), совместимость, локализация — если проверялись. - Если направление не проверялось — так и укажи (не пропускай молча). 7. **Метрики** (где данные позволяют, без натягивания) - Плотность дефектов (дефекты на объём кода/на фичу), процент упавших кейсов, покрытие кода (общее и на новом коде/diff), доля автоматизации, время прогона. Каждая метрика — с источником; если не считается — не выдумывай. 8. **Вердикт / рекомендация** - Одной фразой: **готово к релизу** / **готово с оговорками** / **не готово**. - Обоснование из данных отчёта; при «с оговорками» — список условий; при «не готово» — список блокеров. Согласуй с release-readiness, если он проводился, — не противоречь его вердикту без объяснения. 9. **Приложения** - Ссылки на баги (тикеты), детальные логи прогонов, отчёты аудитов (security/performance/a11y), тест-план/чек-листы, артефакты покрытия, скриншоты. Всё, что подтверждает цифры верхних разделов. ## EDGE CASES, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ - «Все тесты зелёные» при том, что гонялся только unit, а E2E/интеграционные не запускались вовсе — отчёт создаёт ложную уверенность. - Раздел «что не тестировалось» отсутствует — 0 находок читается как гарантия качества. - Blocked-кейсы посчитаны как passed или просто выпали из сводки — реальное покрытие завышено. - Дефекты закрыты как «won't fix»/«не воспроизводится», но остаются реальными рисками — не отражены в known issues. - Покрытие кода приведено общим числом по репозиторию (высокое за счёт старого кода), а на новом коде релиза оно низкое — метрика вводит в заблуждение. - Открытый Critical/High в периметре, но вердикт «готово» — вердикт не следует из данных. - Числа взяты «на глаз» без ссылки на прогон/тикет — отчёт невозможно перепроверить. - Нефункциональные направления (перф/безопасность/a11y) молча пропущены, хотя релиз их затрагивает. - Flaky-падения посчитаны как реальные дефекты (или наоборот, реальные баги списаны на флаки) — искажает и метрики, и вердикт. - Отчёт по «релизу», но набор вошедших тикетов не сверен с диапазоном коммитов — часть изменений не отражена. - Executive summary написан на техжаргоне — стейкхолдеры не считывают решение. - Метрики посчитаны от неполных данных и поданы как точные — плотность дефектов «низкая», потому что половину области не тестировали. ## КРИТЕРИИ КАЧЕСТВЕННОГО ОТЧЁТА (DoD) - Есть executive summary с вердиктом одной фразой в начале. - Есть раздел «что НЕ тестировалось». - Каждая цифра сопровождена источником (прогон/тикет/отчёт). - Дефекты разбиты по severity и статусу; блокеры выделены. - Есть оценка остаточных рисков и known issues. - Вердикт следует из данных и не противоречит release-readiness (если был). - Пробелы в данных помечены явно, а не заполнены выдумкой. - Верх — для менеджмента, детали — в приложениях. ## ФОРМАТ РЕЗУЛЬТАТА Сохрани отчёт в `docs/qa/reports/.md` (slug — по версии/циклу; следуй существующей структуре репозитория, если она есть, иначе создай `docs/qa/reports/`). Продублируй executive summary и вердикт в чат. Документ строй по разделам 1–9 выше, с вердиктом одной фразой в самом начале. ## ПРАВИЛА ОФОРМЛЕНИЯ - Перед началом проверь, нет ли уже отчёта по этому циклу/релизу в `docs/qa/reports/` — если есть, обнови его (новые прогоны, изменившиеся статусы дефектов), а не создавай дубликат. - Дефекты указывай стабильными ID из трекера (со ссылкой), не переприсваивай свои. - Не копируй чужие отчёты дословно — ссылайся на них как на приложения и своди их выводы. ## ЗАПУСК (практическая инструкция) 1. Сначала САМ определи SCOPE отчётности (релиз/цикл/фича) — этот шаг зависит от контекста диалога, не делегируй. 2. Определи CI/трекер/структуру `docs/qa` проекта; собери доступные данные: прогоны тестов, фильтры дефектов, существующие отчёты аудитов и release-readiness. 3. Где можешь дёшево добрать данные — сделай это (запусти доступные тесты и приложи вывод; запроси фильтр трекера). Где нужна глубокая проверка, которой не было, — не проводи её здесь, а зафиксируй как непокрытое. 4. Если объём большой и доступен Agent tool — делегируй сбор по областям (например, отдельный субагент собирает статус нефункциональных проверок из `docs/qa`/`docs/bugs`), передав ему конкретные пути; субагент не видит этот файл. 5. Собери документ по разделам, выведи вердикт одной фразой, честно пометь пробелы, сохрани отчёт и продублируй summary в чат. Это отчётность, а не имплементация и не само тестирование: инструменты редактирования кода недоступны намеренно. Ты фиксируешь и подаёшь результаты тестирования и даёшь рекомендацию; исправления и повторные прогоны — за командой.