понедельник, 23 июня 2008 г.

Что такое Баг Репорт?

Баг Репорт. Дефект


Баг/дефект репорт - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Основные поля баг/дефект репорта


Шапка

Короткое описание (Summary)

Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Важность (Severity)

Наиболее распространена пяти уровневая система

  • S1 Блокирующий (Blocker)
  • S2 Критический (Critical)
  • S3 Значительный (Major)
  • S4 Незначительный (Minor)
  • S5 Тривиальный (Trivial)
(подробнее смотрите ниже в разделе Важность дефекта)

Приоритет (Priority)

Приоритет дефекта:

  • P1 Высокий (High)
  • P2 Средний (Medium)
  • P3 Низкий (Low)
(подробнее смотрите ниже в разделе Приоритет дефекта)

Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия / ... Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.
...  
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Важность дефекта (Severity)


S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшее тестирование системы или ее ключевой функции становится недоступно. Решение проблемы необходимо для дальнейшей работы.

S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дырка в системе безопасности, проблема, вызвавшая падение сервера или приводящее в нерабочее состояние некоторую часть системы, без возможности решения проблемы используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.

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

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.


Приоритет дефекта (Priority)


P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low


Требования к количеству открытых дефектов

Наличие открытых ошибок с S1, S2, P1, P2 считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.

Наличие строго ограниченного количества открытых ошибок S3, S4, S5, P3 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.

Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований - План Тестирования пункт Критерии Окончания Тестирования.

Отправить комментарий

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.