Index
Project Maintenance Service
*О сервисе *Новости *Проекты *Пользователи *Справочная
pms
О проекте
НовостиRSS
СтатьиRSS
Каталог статей
Команда
Багтреккер
Найти сообщение
Секции
Контрольные точки

Система отслеживания ошибок

Опубликовал: shade
Дата публикации: 03.11.2007
Дата правки: 06.09.2008
Промотров: 3491

Абстракт

В данной статье описывается система отслеживания ошибок Шаманграда. Данная статья ориентируется в первую очередь на тех, кто ранее не пользовался системой отслеживания ошибок. Перед прочтением этой статьи (или хотя бы после прочтения) рекомендуется прочесть две статьи Джоэла Сполски: «Тест Джоэла: 12 шагов к лучшему коду» и «Работа над ошибками малой кровью». В прочем у него много интересных статей

Вводная

Я хотел написать небольшую вводную, но она оказалась довольно большой и не уместной для руководства, потому обойдемся без введения. Если же вы уже поняли, что пора всё-таки поближе познакомиться с этим инструментом, эта статья для вас — она ориентируется в первую очередь на новичков ни когда не имевших дел с отслеживанием ошибок. Тем не менее, я не буду в данной статье описывать основы отслеживания ошибок, для этого рекомендую прочесть статью «Работа над ошибками малой кровью», там даже приводиться хороший пример отслеживания ошибки. А в этой статье будет лишь описание конкретной реализации используемой на нашем сервисе.

Атрибуты ошибки

Все ошибки сохраняются в базе данных, и каждая ошибка обладает набором атрибутов:

  • Уникальный код ошибки –– каждая ошибка снабжается уникальным номером-кодом, который можно использовать для ссылок. Нумерация общая для всех проектов.
  • Статус ошибки –– определяет состояние ошибки, которое меняется с течением времени, читайте об этом подробнее ниже.
  • Секция — владелец каждого проекта может определить свой набор секций, их названия и назначение. Об использовании секций написано в отдельной статье «Секции».
  • Контрольная точка — указывает событие до которого должна быть исправлена ошибка или решена задача.
  • Автор сообщения — пользователь (тестер), который отправил сообщение об ошибке. Роль тестера не ограничивается сообщением об ошибке. Тестер должен подробно описать ошибку и проверить решение. Если ошибка решена (исправлена, признана неподдающейся исправлению или являющейся особенностью системы), то тестер должен закрыть сообщение об ошибке. Только после закрытия ошибки, работа над ошибкой считается завершенной.
  • Назначенный разработчик — разработчик которому поручено исправить ошибку.

Статус ошибки и жизненный цикл ошибки

Каждое сообщение об ошибке «живет» своей жизнью, проходит различные этапы. Статус ошибки отражает состояние, этап работы над ошибкой. Сначала, когда ошибка добавляется, она получает статус «Открыта» — с этого начинает каждое сообщение об ошибке. Далее, разработчик должен проверить ошибку, для этого он должен повторить действия приведенные тестером и убедиться, что ошибка имеет место (тогда он меняет статус ошибки на «Признана»). Если описанное поведение тестируемой программы не повторяется или не является ошибкой (например, является особенностью), то статус меняется на «Не ошибка». Разработчик может сменить статус сообщения на «Обратная связь», если считает, что тестер привел недостаточное или неполное описание, в результате чего становиться невозможным исправление ошибки или если просто требуется отклик от тестера (комментарий, ответ на дополнительный вопрос)…

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

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

Назначенный разработчик

В каждый конкретный момент над исправлением каждой ошибки работает только один разработчик, которому назначено исправление ошибки. Ответственность за решение ошибки может передаваться от одного разработчика к другому. Изначально, когда отправляется сообщение об ошибке, оно автоматически назначается разработчику указанному в секции. Далее назначенный разработчик может передать сообщение другому разработчику. У ошибки может отсутствовать назначенный разработчик и такую ошибку может взять себе любой разработчик команды.

Контрольные точки

Для проекта могут быть определены контрольные точки. Каждое сообщение об ошибке может отмечаться контрольной точкой. Если сообщение отмечено контрольной точкой, то его нужно решить до наступления события контрольной точки. Изначально все сообщения добавляются без контрольной точки и только разработчики могут менять контрольную точку сообщения.

Комментарии пользователей

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

Bold Картинка Картинка с подписью Цитата Код Отключение BB-кодов
Меню системы
О сервисе
НовостиRSS
Справочная
Проекты
Пользователи
Вход
Регистрация
Переход к багу