Тест-кейсы, чек-листы и баг-репорты: как оформлять тестирование

Тест-кейсы, чек-листы и баг-репорты

На прошлых лекциях мы разобрали, что такое тестирование и как придумывать тесты (классы эквивалентности, граничные значения). Но мало просто «придумать» — нужно оформить свои проверки так, чтобы их поняли коллеги, разработчики и заказчик.

Сегодня мы разберём три главных документа тестировщика: тест-кейс, чек-лист и баг-репорт.

📋 Тест-кейс ✅ Чек-лист 🐞 Баг-репорт

                     Это третья лекция из цикла. Она посвящена документированию тестирования. Без этого навыка тестировщик не сможет работать в команде.
                

Формат: лекция + практика в конце. В следующей лекции — модульное тестирование на Python/C++.

План лекции

Сегодня мы разберём три документа, которые сопровождают тестирование.

1 Зачем документировать тестирование
2 Тест-кейс: структура и поля
3 Хороший и плохой тест-кейс
4 Чек-лист: когда он нужен
5 Отличие чек-листа от тест-кейса
6 Баг-репорт: структура и поля
7 Хороший и плохой баг-репорт
8 Приоритет и серьёзность дефекта
9 Жизненный цикл бага
10 Типичные ошибки
11 Итоги и практика

Если вы пропустили первые две лекции — вернитесь. Без понимания тест-дизайна эти документы будут пустыми.

Зачем документировать тестирование

Многие новички думают: «Зачем писать какие-то бумажки? Я и так помню, что нужно проверить». Но это работает только для маленьких учебных проектов.

Аналогия. Представьте, что вы строите дом. Без чертежа можно построить сарай. Но многоэтажный дом без чертежа построить невозможно. Тест-кейсы — это «чертёж» тестирования.

🧠

Память
Вы не забудете, что именно нужно проверить.

👥

Команда
Коллега сможет выполнить ваши тесты без вас.

📈

Повторяемость
Тесты можно выполнять снова и снова после изменений в коде.

📊

Отчётность
Руководство видит, что именно было проверено.

Хорошо оформленные тесты — это актив команды. Они живут годами и помогают не наступать на одни и те же грабли.

Тест-кейс: структура

Тест-кейс (test case) — это описание проверки: что подаём на вход, что ожидаем получить и при каких условиях.

ПолеЧто значитПример IDуникальный номерTC-01 Названиечто проверяемСложение двух положительных чисел Предусловиечто должно быть выполнено до тестаКалькулятор запущен Шагипоследовательность действий1. Ввести 3. 2. Нажать +. 3. Ввести 5. 4. Нажать = Ожидаемый результатчто должно быть8 Фактический результатчто получилось(заполняется при выполнении) Статуспройден или нетPassed / Failed

Тест-кейс должен быть написан так, чтобы любой человек мог его выполнить и получить тот же результат.

Пример тест-кейса

Вот как выглядит правильно оформленный тест-кейс.

// Тест-кейс TC-01 ID: TC-01 Название: Сложение двух положительных чисел Предусловие: Калькулятор запущен, поле ввода пустое Шаги: 1. Ввести первое число: 3 2. Нажать кнопку «+» 3. Ввести второе число: 5 4. Нажать кнопку «=» Ожидаемый результат: 8 Фактический результат: 8 Статус: Passed Автор: Иванов Иван Дата: 2026-10-25

Такой тест-кейс может выполнить любой человек, даже не знакомый с программой. Это и есть цель.

Хороший и плохой тест-кейс

Давайте сравним два тест-кейса для одной и той же проверки.

❌

Плохой
«Проверить сложение».

Непонятно: какие числа? что ожидается? как выполнять?

✅

Хороший
«Ввести 3, нажать +, ввести 5, нажать =. Ожидается 8».

Всё понятно: что делать и что ожидать.

                    Хороший тест-кейс отвечает на три вопроса:

                    1. Что делаем? (шаги)

                    2. Что ожидаем? (ожидаемый результат)

                    3. Как понять, что прошло? (критерий успеха)

Чек-лист: что это

Чек-лист (checklist) — это список проверок без подробных шагов. Он короче тест-кейса, но менее детальный.

// Чек-лист для калькулятора ☐ Сложение двух положительных чисел ☐ Сложение двух отрицательных чисел ☐ Вычитание положительных чисел ☐ Умножение на ноль ☐ Деление на ноль (должна быть ошибка) ☐ Ввод буквы вместо числа (должна быть ошибка)

КритерийТест-кейсЧек-лист Детализациявысокаянизкая Длинадлинныйкороткий Кто может выполнитьлюбойнужен опыт Когда использоватьсложные проверкибыстрая проверка

Чек-лист — это «напоминалка» для опытного тестировщика. Тест-кейс — это «инструкция» для любого человека.

Баг-репорт: структура

Баг-репорт (bug report) — это документ, в котором тестировщик описывает найденный дефект так, чтобы программист мог его воспроизвести и исправить.

ПолеЧто значитПример IDуникальный номерBUG-01 Заголовоккраткое описаниеДеление на ноль не вызывает ошибку Окружениегде воспроизводитсяWindows 11, калькулятор v1.0 Шагикак повторить1. Открыть. 2. Ввести 5 / 0. 3. Нажать = Ожидаемый результатчто должно бытьСообщение «Ошибка: деление на ноль» Фактический результатчто произошлоПрограмма показывает 0 Приоритетнасколько критичноВысокий

Пример баг-репорта

Вот как выглядит правильно оформленный баг-репорт.

// Баг-репорт BUG-01 ID: BUG-01 Заголовок: Деление на ноль возвращает 0 вместо ошибки Окружение: Windows 11, Калькулятор v1.0 Шаги: 1. Запустить калькулятор. 2. Ввести первое число: 5. 3. Нажать кнопку «/». 4. Ввести второе число: 0. 5. Нажать «=». Ожидаемый результат: сообщение «Ошибка: деление на ноль» Фактический результат: калькулятор показывает 0 Приоритет: Высокий Автор: Иванов Иван Дата: 2026-10-25

Обратите внимание: в баг-репорте обязательно есть шаги воспроизведения. Без них программист не сможет повторить ошибку и понять, что исправлять.

Хороший и плохой баг-репорт

Сравним два баг-репорта для одной и той же ошибки.

❌

Плохой
«Калькулятор не работает».

Непонятно: что именно не работает? как повторить? что ожидалось?

✅

Хороший
«При делении 5 на 0 программа показывает 0 вместо ошибки».

Всё понятно: что делали, что ожидали, что получили.

                    Хороший баг-репорт отвечает на три вопроса:

                    1. Что делали? (шаги)

                    2. Что ожидали? (ожидаемый результат)

                    3. Что получили? (фактический результат)

Приоритет и серьёзность

В баг-репорте часто указывают два параметра: серьёзность (severity) и приоритет (priority). Это не одно и то же.

ПараметрЧто значитПример Серьёзностьнасколько сильно баг ломает функциональностьКритический: программа падает Приоритетнасколько срочно нужно исправитьВысокий: исправить сегодня

Аналогия. Опечатка в названии компании на главной странице сайта — это низкая серьёзность (функциональность не сломана), но высокий приоритет (репутация дороже). А ошибка в расчёте налогов — высокая серьёзность и высокий приоритет.

Серьёзность определяет тестировщик. Приоритет — менеджер или разработчик.

Жизненный цикл бага

Баг — это не статичная запись. У него есть свой «жизненный цикл».

New (Новый)

↓

Assigned (Назначен разработчику)

↓

In Progress (В работе)

↓

Fixed (Исправлен)

↓

Verified (Проверен)

↓

Closed (Закрыт)

Если после проверки баг всё ещё воспроизводится, он возвращается в статус Reopened (переоткрыт). И цикл продолжается.

Типичные ошибки новичков

1. «Не работает»
Без конкретики. Непонятно, что именно не работает и как это повторить.

2. Нет шагов воспроизведения
Разработчик не может повторить ошибку.

3. Нет ожидаемого результата
Непонятно, что должно было быть.

4. Смешение нескольких багов в одном
Один баг — одна запись. Иначе сложно отслеживать.

5. Эмоции вместо фактов
«Ужасная программа» — не описание бага. Только факты: что сделали, что ожидали, что получили.

Практическое задание

Примените полученные знания на практике.

Задание 1

Напишите тест-кейс для функции «деление двух чисел» (с проверкой деления на ноль).

Задание 2

Составьте чек-лист из 5 пунктов для проверки формы ввода пароля.

Задание 3

Оформите баг-репорт для ошибки: «При вводе буквы вместо числа программа падает с ошибкой».

Решения разберём на практическом занятии. Не бойтесь ошибаться — важно научиться оформлять мысли.

Шпаргалка

Сохраните этот слайд — здесь все основные понятия лекции.

ТерминЧто значит Тест-кейсподробное описание проверки Чек-листкраткий список проверок Баг-репортописание дефекта Серьёзностьнасколько сильно ломает функциональность Приоритетнасколько срочно исправлять Жизненный цикл багаNew → Assigned → Fixed → Verified → Closed

Итоги лекции

Подведём итоги. Вот что вы теперь знаете.

✅ Тест-кейс — подробное описание проверки с шагами и ожидаемым результатом.
✅ Чек-лист — краткий список проверок без деталей.
✅ Баг-репорт — описание дефекта с шагами воспроизведения.
✅ Серьёзность и приоритет — разные параметры.
✅ Жизненный цикл бага: New → Assigned → Fixed → Verified → Closed.
✅ Хороший баг-репорт отвечает на три вопроса: что делали, что ожидали, что получили.

В следующей лекции мы перейдём к практике — модульному тестированию на Python и C++. Вы научитесь писать автоматические тесты для своих функций.

Домашнее задание

Задания для самостоятельной работы. Первые два обязательны, остальные — для оценки «отлично».

Напишите 3 тест-кейса для функции «проверка пароля» (длина от 8 до 20 символов).
Составьте чек-лист из 10 пунктов для проверки формы регистрации.
Оформите баг-репорт для ошибки «При вводе email без символа @ программа не выдаёт ошибку».
Найдите в интернете пример реального баг-репорта и сравните его со своим.
Объясните своими словами, чем отличается серьёзность от приоритета.

Если задание кажется сложным — разбейте его на части. Сначала один тест-кейс, потом ещё два.

Что дальше?

В этом блоке по тестированию у нас ещё несколько материалов.

Практика 2: модульное тестирование на Python и C++.
Лекция 4: покрытие кода и метрики (MC/DC).
Практика 3: интеграционное тестирование.

Документирование — это навык, который отличает профессионала от новичка. Умение оформлять тесты и баги ценится в любой IT-команде.

Спасибо за внимание!

📋

Хороший тестировщик — это ещё и хороший писатель

Умение чётко описать проблему — половина её решения. Тест-кейсы, чек-листы и баг-репорты — ваш главный инструмент.

📋 Тест-кейсы ✅ Чек-листы 🐞 Баг-репорты 🚀 практика