В прошлом уроке мы научились следить за ходом тестирования: мониторинг давал цифры, метрики показывали картину, контроль превращал тревожные сигналы в решения. Но цикл тестирования не бесконечен — рано или поздно он заканчивается, и нужно подвести итог. Разберём последний документ этой главы — итоговый отчёт о тестировании — и то, как сообщить его результат людям, которые не читали ни тест-план, ни один баг-репорт.
Чему научишься за этот урок:
— отличать итоговый отчёт о тестировании от баг-репорта и от ежедневной метрики;
— называть, что входит в итоговый отчёт, и готовить краткий статус для нетехнических стейкхолдеров;
— формулировать обоснованную рекомендацию о готовности релиза.
Итоговый отчёт: сводка по всему циклу, а не один дефект и не снимок дня
Важно не перепутать три разных документа. Баг-репорт (глава 6.4) описывает ОДИН конкретный дефект: заголовок, шаги, факт, ожидание. Метрики из прошлого урока — это снимок хода тестирования В ОДИН МОМЕНТ, посреди цикла. Итоговый отчёт о тестировании (test summary report) — третий, отдельный документ: сводка по итогам ВСЕГО цикла или релиза целиком, когда тестирование уже закончено или подходит к концу. В него входят пять частей:
- План и факт. Что было запланировано по тест-плану (глава 13.1) и что реально сделано — какая часть объёма закрыта.
- Статистика дефектов. Сколько дефектов найдено всего, с разбивкой по severity (глава 6.6) — сколько высоких, средних, низких.
- Критерии выхода. Достигнуты они или нет (урок 13.2) — и если нет, то какой именно критерий не выполнен.
- Непокрытые риски. Какие риски продукта или проекта (урок 13.3) остались нейтрализованы не полностью на момент завершения.
- Рекомендация. Итоговый вывод: готов релиз или нет, и почему.
ПЛАН (тест-план, 13.1) -> ФАКТ (что реально сделано) -> ДЕФЕКТЫ ПО SEVERITY (6.6) -> КРИТЕРИИ ВЫХОДА достигнуты? (13.2) -> НЕПОКРЫТЫЕ РИСКИ (13.3) -> РЕКОМЕНДАЦИЯ о готовности релиза
Коммуникация статуса: не всем нужен детальный отчёт
Итоговый отчёт часто адресован не только команде разработки, которая понимает термины severity и критерии выхода без пояснений, но и людям без глубокого технического контекста — продакт-менеджеру, руководству. Для них кроме детального отчёта нужен КРАТКИЙ статус, понятный без объяснения технических терминов. Частый формат — светофорный: зелёный (готово), жёлтый (есть риски), красный (не готово) — с одной строкой обоснования на понятном языке. Например: «Жёлтый — все ключевые функции работают, но остаётся один неисправленный дефект с высоким severity в оплате картой; рекомендуем на день отложить релиз».
Рекомендация о готовности релиза
Тестировщик не решает единолично, выпускать релиз или нет — финальное решение часто остаётся за продакт-менеджером или руководителем проекта (вспомните границы ответственности, глава 12.2). Но тестировщик обязан дать явную, обоснованную данными рекомендацию, а не расплывчатое «в целом норм» или «есть вопросы». Хорошая рекомендация звучит конкретно: «Рекомендую отложить релиз, потому что не пройден критерий выхода — остаётся один открытый дефект с высоким severity» или «Рекомендую релиз: все критерии выхода достигнуты, открытых дефектов высокого severity нет».
Пример: итоговый отчёт для «Отзывы о курсах»
Вернёмся к разделу «Отзывы о курсах» из первого урока главы. Итоговый отчёт мог бы выглядеть так: план и факт — по тест-плану проверяли форму отправки отзыва, шкалу оценки и отображение отзывов на странице курса (email-уведомления были вне границ и не проверялись); весь запланированный объём выполнен. Статистика дефектов — найдено три дефекта: один с высоким severity (отзыв с оценкой 0 звёзд проходит валидацию и портит отображение рейтинга), два с низким (мелкие визуальные неровности шкалы на мобильном). Критерии выхода — не достигнуты: критерий «ноль открытых дефектов высокого severity» из тест-плана не выполнен, дефект с оценкой 0 звёзд ещё не исправлен. Непокрытые риски — риск, связанный с модерацией отзывов (модерация ещё не реализована технически, как отмечалось в уроке 13.1), остаётся не закрыт и на момент отчёта. Рекомендация — отложить релиз до исправления дефекта с оценкой 0 звёзд и его перепроверки; оставшиеся два дефекта низкого severity можно исправить уже после релиза.
Совет: если детальный отчёт получился длинным, не рассчитывай, что руководство прочитает его целиком перед решением. Светофорный статус с одной строкой обоснования — это не упрощение ради лени, а отдельный, специально подготовленный артефакт для другой аудитории.
Итог:
— итоговый отчёт о тестировании — сводный документ по всему циклу (план и факт, дефекты по severity, критерии выхода, непокрытые риски, рекомендация), а не баг-репорт и не ежедневная метрика;
— для нетехнических стейкхолдеров нужен отдельный краткий статус — например, светофорный формат с одной строкой обоснования;
— тестировщик не решает о релизе единолично, но обязан дать явную рекомендацию, подкреплённую данными;
— вместе с тест-планом (13.1), критериями входа/выхода (13.2), рисками (13.3) и мониторингом с метриками (13.4) итоговый отчёт закрывает единый цикл управления тестовой деятельностью: спланировали, определили границы готовности, расставили приоритеты по рискам, следили за ходом, подвели итог и дали рекомендацию.
Контрольный вопрос. Чем итоговый отчёт о тестировании отличается от баг-репорта (глава 6.4)?
Подсказка: Баг-репорт всегда про один дефект — подумай, о чём вместо этого документ этого урока.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какая информация относится к разделу итогового отчёта «Статистика дефектов»?
Подсказка: Название раздела прямо подсказывает, какая это статистика — дефектов, а не людей и не сроков.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Зачем нужен краткий светофорный статус в дополнение к детальному итоговому отчёту?
Подсказка: Подумай, кто, кроме команды разработки, может читать этот статус — и что они не обязаны знать термины.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Кто, согласно уроку, чаще всего принимает финальное решение о выпуске релиза?
Подсказка: Тестировщик участвует в решении, но роль, которая формально его принимает, — не тестировщик.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что обязательно должно быть отражено в итоговом отчёте о тестировании (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Три варианта — это конкретное содержание отчёта, один — не имеет отношения к тестированию.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется документ-сводка по итогам всего цикла тестирования: план и факт, дефекты по severity, критерии выхода, непокрытые риски и рекомендация? Ответь двумя словами.
Подсказка: Название уже встречалось в первом абзаце этого раздела урока — это не баг-репорт и не метрика.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. В итоговом отчёте написано: «Найдено 3 дефекта: 1 с высоким severity, 2 — с низким». К какому из пяти разделов итогового отчёта относится эта информация? Ответь двумя словами, как раздел назван в уроке.
Подсказка: Это не про план, не про критерии выхода и не про риски — это именно про сами дефекты и их тяжесть.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. В отчёте по разделу «Оплата курса» написано: «Открыт один дефект с высоким severity, что не соответствует условию тест-плана «ноль открытых дефектов высокого severity»». К какому разделу итогового отчёта относится это наблюдение? Ответь двумя словами.
Подсказка: Речь про условие, при котором тестирование можно считать завершённым, — оно разбиралось в отдельном уроке этой главы.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях, почему итоговый отчёт о тестировании — это не то же самое, что метрики из прошлого урока (13.4), хотя оба документа опираются на похожие данные (например, число дефектов по severity).
Критерий приёмки: указано, что метрики — это снимок хода тестирования в один момент, посреди цикла, без окончательных выводов; указано, что итоговый отчёт составляется по итогам всего цикла и содержит финальную рекомендацию, которой у метрик нет; роли двух документов не перепутаны.
Подсказка: Вспомни, в какой момент цикла составляется каждый из двух документов — посредине или в конце.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Раздел «Каталог курсов» протестирован по тест-плану полностью. Итог: выполнены все запланированные тест-кейсы; найдено два дефекта — один с низким severity (неровность отступа на мобильном), один со средним severity (сортировка курсов по цене иногда не применяется с первого клика, но применяется со второго); критерий выхода тест-плана «ноль открытых дефектов высокого severity» формально выполнен, дефектов высокого severity нет; риск «сложность фильтрации» из анализа рисков (глава 13.3) подтвердился частично именно в найденном дефекте сортировки. Составь короткий итоговый отчёт по пяти разделам из этого урока и дай явную рекомендацию о готовности релиза.
Критерий приёмки: заполнены все пять разделов (план и факт; статистика дефектов; критерии выхода; непокрытые риски; рекомендация); статистика дефектов верно указывает один низкий и один средний severity, а не высокий; критерии выхода отмечены как формально достигнутые; рекомендация явно сформулирована («рекомендую релиз» или «рекомендую отложить») и обоснована данными сценария, а не общей фразой.
Подсказка: Пройдись по всем пяти разделам по очереди, и в критериях выхода отдельно учти, что формально они выполнены, даже если остался неисправленный дефект среднего severity.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Это последний урок главы «Управление тестовой деятельностью». Мы прошли полный цикл: тест-план задал структуру и границы (13.1), критерии входа и выхода определили, когда начинать и когда можно закончить (13.2), анализ рисков расставил приоритеты (13.3), мониторинг и метрики держали руку на пульсе во время самого тестирования (13.4), а итоговый отчёт подвёл черту и дал обоснованную рекомендацию (этот урок). Дальше в курсе — глава «ИИ-помощник тестировщика»: где ИИ реально ускоряет типовую работу и что он систематически упускает.
