Рассмотрим схему типового дефекта, его основные составные части, параметры и атрибуты. На схеме представлен пожалуй минимальный необходимый набор полей, который требуется использовать при описании ошибки. В этом случае дефект станет понятен и разработчику, который будет с ним работать, и другим членам команды тестирования, и сам тестировщик, который создал этот дефект, спустя длительное время сможет быстро понять о чем в нем идет речь. Фактически, грамотное и полное описание дефекта (как и других артефактов тестирования) дает возможность работать с ним любому участнику процесса разработки ПО без постоянных вопросов к инициатору.
Далее рассмотрим, почему именно такие поля необходимы при описании дефекта.
Параметры дефекта
- Номер (ID) дефекта – уникальный (например, числовой) идентификатор
- Краткое описание ошибки – одна или несколько фраз, из которых ясна суть проблемы
- Ссылка на тест-кейс\требования – прямая ссылка или указание названия и версии документа с требованиями
- Название\модуль\ версия ПО – точное описание тестируемого ПО
- Автор дефекта – тестировщик, описавший ошибку
- На кого назначен дефект – тот, кто на данный момент работает с дефектом
- Статус дефекта – текущее состояние дефекта (например, «открыт», «назначен», «в работе»)
- Срочность дефекта (Priority) – как быстро дефект должен быть исправлен с точки зрения задач проекта
- Критичность дефекта (Severity) – насколько важным является дефект с точки зрения функциональности
Данные для воспроизведения ошибки
- Логи, скриншоты, доп.материалы описывающие ошибку – все дополнительные материалы, которые помогут понять и проанализировать ошибку
- Данные для воспроизведения ошибки – набор условий и данных, при которых была обнаружена ошибка
Шаги воспроизведения ошибки
- Шаги для воспроизведения - кратко и четко описанные действия, необходимое для воспроизведения ошибки
- Ожидаемый результат - что должны получить после каждого действия в соответствии с требованиями
- Фактический результат – несоответствие требованиям, которое получаем в реальности