Жизненный цикл дефекта. Системы документирования дефектов (bug-tracking systems). Классификация и принципы описания дефекта (bug report).

Дефект (он же баг) – это несоответствие фактического результата выполнения программы ожидаемому результату. Дефекты обнаруживаются на этапе тестирования программного обеспечения (ПО), когда тестировщик проводит сравнение полученных результатов работы программы (компонента или дизайна) с ожидаемым результатом, описанным в спецификации требований.

ЖЦ дефекта

Итак, мы нашли баг. Может даже блокер. Что же с ним может случится, на всём его нелегком жизненном пути? (Названия этапов жизни дефектов могут быть разными в разных баг-трекинг системах, но суть их одна).

Обнаружен (Submitted) – тестировщик нашел баг. Состоялось «рождение» дефекта в QA-мире.

Новый (New) – дефект успешно занесен в систему.

После этого, в зависимости от решения менеджера проекта, баг может быть:

Отклонен (Declined). По разным причинам дефект может и не считаться дефектом или считаться неактуальным дефектом, что вынуждает отклонить его.

Отложен (Deferred). Исправление этого бага не несет ценности на данном этапе разработки или по другим, отсрочивающим его исправление причинам.

Открыт (Opened). Ответственное лицо признало дефект дефектом, при чем таким, который нужно исправить.

Когда наличие дефекта неопровержимо, его путь может привести к следующим статусам:

Назначен (Assigned). Исправление текущего бага возложено на плечи определенного разработчика.

Исправлен (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.

В зависимости от того, исправил ли разработчик дефект, дефект может быть:

Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект, или все-таки разработчик безответственный. Если бага больше нет, он получает данный статус.

Повторно открыт (Reopened). Если опасения тестировщика оправданы и баг в новом билде не исправлен – он все так же потребует исправления, поэтому заново открывается.

Закрытый (Fixed). В результате определенного количества циклов баг все-таки окончательно устранен и больше не потребует внимания команды – он объявляется закрытым.

Классификация дефектов

Классификация дефектов, с точки зрения степени влияния (Severity) на работоспособность ПО:

Blocker. Ошибка, которая приводит программу в нерабочее состояние. Дальнейшая работа с программной системой или ее функциями – невозможна.

Critical. Критический дефект, приводящий некоторый ключевой функционал в нерабочее состояние. Так же это может быть существенное отклонение от бизнес логики, неправильная реализация требуемых функций, потеря пользовательских данных и т.д. Major. Весьма серьезная ошибка, свидетельствующая об отклонении от бизнес логики или нарушающая работу программы. Не имеет критического воздействия на приложение.

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

Trivial. Баг, не имеющий влияние на функционал или работу программы, но который может быть обнаружен визуально. Например, ошибка в тексте.

Градация дефектов, с точки зрения приоритетности исправления (Priority):High. Баг должен быть исправлен как можно быстрее, т.к. он критически влияет на работоспособность программы.

Medium. Дефект должен быть обязательно исправлен, но он не оказывает критическое воздействие на работу приложения.

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

Принципы описания дефектов

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

В общем случае, баг репорт состоит из:

Шапка.

Короткое описание (короткое описание проблемы).

Проект (название текущего проекта).

Компонент приложения (в котором возник дефект).

Версия (версия билда, в котором найден баг).

Серьезность (градация степени влияния на приложение бага).

Приоритет (очередь исправления бага).

Статус (отображает статус бага в своем жизненном цикле).

Автор (автор баг репорта).

Назначение (кто должен исправить дефект).

Окружение.

Операционная система, разрядность, Сервис Пак, браузер, его версия и т.д.

Описание.

Шаги воспроизведения (описание пути, который приводит к возникновению дефекта).

Фактический результат (результат, к которому приходим выполнив все шаги воспроизведения).

Ожидаемый результат (результат, который быть в соответствии с требованиями).

Дополнения.

Прикрепленный файл (логи, скриншоты, другие документы, которые могут помочь воспроизвести проблему или решить ее).

Несмотря на такое большое количество пунктов баг репорта, можно выделить несколько основных полей, присутствие которых необходимо:

Краткое описание. Поле, в котором нужно поместить весь смысл всего баг репорта. Чаще всего, в коротком описании лаконично отвечают на 3 вопроса: «Где?», «Что?», «Когда?» (именно в такой последовательности, как бы не хотелось изменить ее по примеру всем известной игры).

Серьезность. Дефект либо полностью останавливает работоспособность приложения, либо только часть функциональности, либо иное.

Шаги к воспроизведению. Точное и понятное описание всех шагов, которые приводят к появлению дефекта, с учетом всех необходимых входных данных и т.д.

Фактический результат.

Ожидаемый результат.

Состав, назначение и принципы организации тест-плана.

План тестирования (test plan) - документ, описывающий цели, подходы, ресурсы и график запланированных тестовых активностей. Он определяет объекты тестирования, свойства для тестирования, задания, ответственных за задания, степень независимости каждого тестировщика, тестовое окружение, метод проектирования тестов, определяет используемые критерии входа и критерии выхода и причины их выбора, а также любые риски, требующие планирования на случай чрезвычайных обстоятельств.

Каждая методология или процесс пытаются навязать свои форматы оформления планов тестирования. Однако хороший тест план должен как минимум описывать следующее:

Что надо тестировать? o описание объекта тестирования: системы, приложения, оборудования