Жизненный цикл дефекта (Defect Lifecycle)
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для Вас с целью персонализации сервисов и предложений. Вы можете прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом без изменения настроек, вы даёте согласие на использование ваших cookie-файлов.
speech bubble

Жизненный цикл дефекта (Defect Lifecycle)

Жизненный цикл дефекта (Defect Lifecycle)

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

Дефект (bug, defect) —  расхождение между ожидаемым и фактическим результатом, полученным тестировщиком.

Ошибка (mistake, error) — пользовательские действия, приводящие к ошибочным поведениям приложения.

Отказ (failure) — случаи, нарушающие выполнимость действий системы для получения конечного результата.

Сбой (interruption) — одноразовый отказ, ликвидирующийся быстрым исправлением.

В общем понимании, отказ и сбой в приложении – несоответствие действий тестируемой разработки от ожидаемых результатов

Инцидент (incident) — отчет, информация о дефекте, поступившая через службу технической поддержки.

 

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

После понимания отличий, можно переходить к изучению ЖЦ дефекта. Defect Lifecycle не сильно отличается между разными баг-трекинговыми системами, например, джира (jira) и редмайн (redmine). По непонятным причинам в интернете яростно пытаются разделить jira от остальных статусных схем бага, ибо в каждой команде, разрабатывающей и тестирующей приложение, она сводится к общим этапам с индивидуальными отклонениями.

Жизненный цикл дефекта (Defect Lifecycle) – перечень шагов, проходящих дефектом с момента открытия до окончательного статуса. Статусы дефекта варьируются в зависимости от нужд тестируемого проекта или части системы.

Любой дефект обладает общим жизненным циклом (Defect Lifecycle) и возможными статусами:

  • Этап 1. Новый (New) -  первое добавление описание дефекта в баг-трекинговую систему.
  • Этап 2. Открыто (Open) -  открытие  дефекта, подтверждение и создание отчета в баг-трекинге.
  • Этап 3. В процессе исправления (In Progress) – дефект взят в задания разработчиком.
  • Этап 4. Исправлено (Fixed) – bug исправлен  разработчиком и ожидается ретест.
  • Этап 5. Ретест (Retesting) – повторное тестирование после исправления.
  • Этап 6. Закрыто (Closed) – закрытие  отчета о дефекте после проверки и признания исправления.
  • Этап 7. Переоткрыт (Reopened) – дефект открыт заново.
Жизненный цикл дефекта (Defect Lifecycle)

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

Следовательно, на каждой стадии жизненного цикла баг-репорта появляется статусная схема:

Этап 1:

  • Новый (New) – первое появление баг-репорта в трекере
  • Дубликат (Duplicate) – дефект уже существует в баг-трекинге. «Связывается» с первым багом для объединения.
  • Назначен (Assigned) – назначение репорта на пользователя, тестировщика, в отдельных случаях на разработчика

Этап 2:

  • Открыт (Open) – анализ, редактирование, готовность взять в работу

Этап 3, 4:

  • Исправлен (Fixed) – разработчик добавил исправления в систему, проверил работоспособность и отдал тестировщику.
  • Отклонен (Rejected) – дефект является несущественным, нет необходимости исправлять с согласования аналитиков, руководителя.

Этап 5:

  • Повторное тестирование (Retesting) – повторное тестирование исправлений кода, полученного от разработчика
  • Проверен (Verified) – подтверждение тестировщиком, что дефект исправлен
  • Переоткрыт (Reopened) – проставляется, если баг повторяется снова. Переходящий статус в этап 7. Цикл повторяется с начального этапа.

Этап 6:

  • Закрыт (Closed) – закрытие bug-report. Тестировщик уверен в исправлении дефекта.

Возможные статусы багов на любом из стадий:

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

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

 

Для комментирования необходимо авторизоваться