Системы отслеживания ошибок (bug tracking system BTS) - Жизненный цикл ошибки

E-mail Печать PDF
Рейтинг пользователей: / 7
ХудшийЛучший 
Индекс материала
Системы отслеживания ошибок (bug tracking system BTS)
Зачем нужны BTS
Пример обработки одной ошибки
Классификация программных ошибок
Структура хорошего отчета по ошибке
Основные атрибуты отчета об ошибке
Советы Джоеля Спольски по использования BTS
Жизненный цикл ошибки
Рассмотрение конкретной BTS на примере Mantis
Все страницы

Жизненный цикл ошибки

Итак, тест проведен, ошибка найдена, при этом сомнений в том, что ошибка имеет место - нет. Что делать дальше? Необходимо сообщить разработчику (программисту) о том, что ошибка найдена, т.е. написать отчет о проблеме (bug report).

В bugtraking системе заведём разделы (проекты и продукты). Кто-то (пользователь, другой разработчик и т.д.) находит нужный раздел и вводит сообщение об ошибке. Появился bug в статусе "NEW".

У каждого бага есть свой владелец. Когда bug is "new", он автоматически назначается ответственному ("assigned to"). Bug можно (и часто нужно) переназначить ответственному (reassign).

В практике чаще всего используются следующие состояния багов:

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

Баг переходит в состояние Assigned. По мере работы, этот программист может переадресовать баг другому программисту, который, например, знает данную часть системы лучше. К сожалению, это порождает ситуации, когда баг "плутает" от одного разработчика к другому несколько месяцев.

Assigned - Конкретный программист получил этот баг и теперь должен отвечать "за базар" - исправлять свою или чужую ошибку.

В случае, если ошибка не является "ошибкой" (тестер ошибся) то баг превращается в Resolved-Invalid и переправляется тестеру обратно.

Если баг о той же проблеме уже есть, и над ним работают, то баг превращается в Resolved-Duplication. Например, ошибка была описана ранее и была исправлена, но исправленный код еще не поступил к тестерам.

Когда программист ошибку исправил, то баг превращается в Resolved-Fixed. Сам программист эти состояния и выставляет.

Resolved (Fixed, Invalid, Duplication)- ошибка исправлена и возвращена тестерам для проверки.

Если баг в состоянии Resolved-Invalid то тестер обязан еще раз убедиться, ошибка была или нет. Другими словами перетестировать.

Когда баг в состоянии Resolved-Duplication то тестер должен убедиться, что действительно, другой(ие), аналогичный(ые) баг(и) существует, его номер обычно программер указывает в своем комментарии. Доверяй, но проверяй.

В случае, когда баг Resolve-Fixed тестер проверяет (тестирует проблему) опять. Если ошибка исправлена - Verified (Closed). Если ошибка не исправлена - баг переоткрывается опять (Unconfirmed, Assigned)

Verified ошибка исправлена и перетестирована на тестовой машине.

Closed - ошибка исправлена, перетестирована и исправленный код помещен на живую систему, или новый билд выпущен.



 

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

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры