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

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

Схема в текстовом виде, несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):

1. (новый)new —> (отклоненный)rejected —>(закрытый)closed
2. new —->(отложенный)deferred
3. new —>(принятый)Accepted —>(открытый)open —> (исправленный)fixed —> (закрытый)closed
4. new —-> accepted —->open —->fixed —->closed—->(открыт снова)reopend

Каждый дефект имеет ряд обязательных свойств(properties), которые нужно внести в bug tracking систему при добавлении этого самого дефекта:
1. Уникальный номер (ID) — присваивается автоматически
2. Краткое название (Title, Summary или Short Description): короткий текст, который помогает сразу понять что это за дефект
3. Описание (Description): полное описание дефекта включая шаги для воспроизведения.
4. Окружение: ОС, версия продукта? на котором был найден дефект, браузер, патчи, т.е. конфигурация системы, на который дефект был обнаружен.
5. Attachments — некоторые дефекты сложно описать, для простоты делаются скриншоты, видео, или лог-файлы и прикладываются к описанию ошибки для наглядности (<Alt>+<prt Scr> позволяет скопировать текущий экран в буфер, потом можно воспользоваться любым редактором для сохранения файла)
6. Важность (Severity) этого дефекта – заполняется тестером. Для оценки последствий данного бага с точки зрения «пользователя».
7. Приоритет (Priority) – данное свойство должны заполнять разработчики, либо лид разработчиков. С помощью данного свойства определяется очередность исправления данного дефекта программистом.

А вот цикл, по которому проводится ошибка (bug), попадая в систему учета дефектов(Bug Tracking System)ЖЦ бага

Названия могут отличаться в разных системах, но важно понять смысл:
1. Новый - дефект только найден и внесен в систему.
2. В зависимости от анализа дефекта, его статус меняется на Отказ (Rejected) или на Назначен.
3. Отказ (Rejected) — пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть или некачественное описание дефекта, или такой дефект уже существует (дубликат) или невозможность воспроизвести дефект. После этого, тестер или закрывает дефект (Closed) или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен.
3. Назначен — дефект просмотрен и открыт (можно сказать признан) для исправления.
4. Решен (Fixed) — дефект исправили и он в этом состоянии требует перепроверки тестировщиком (работа тестера:) и такой работы много)
5. После «Fixed» дефект переводится в состояние Переоткрыт (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.

На базе состояний дефектов в системе учета может быть построено множество отчетов, позволяющих оценивать эффективность как команды разработки, так и команды тестирования. А так же ряд метрик позволяющих оценить точки схождения дефектов и в целом «бажность» выпускаемых продуктов. Еще важно отслеживать ошибки, которые приходят уже после выпуска, от службы поддержки, и строить часть метрик с учетом этих сообщений. Позже напишу статью посвященную отчетности.

2 thoughts on “Жизненный цикл бага

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>