Документирование и жизненный цикл дефекта
Каждый дефект, обнаруженный в процессе тестирования, должен быть задокументирован и отслежен. При обнаружении нового дефекта его заносят в базу дефектов. Для этого лучше всего использовать специализированные базы, поддерживающие хранение и отслеживание дефектов - типа DDTS . При занесении нового дефекта рекомендуется указывать, как минимум, следующую информацию:
- Наименование подсистемы, в которой обнаружен дефект.
- Версия продукта (номер build ), на котором дефект был найден.
- Описание дефекта.
- Описание процедуры (шагов, необходимых для воспроизведения дефекта).
- Номер теста, на котором дефект был обнаружен.
- Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.
Занесенный в базу дефектов новый дефект находится в состоянии "New" . После того, как команда разработчиков проанализирует дефект, он переводится в состояние "Open" с указанием конкретного разработчика, ответственного за исправление дефекта. После исправления дефект переводится разработчиком в состояние "Resolved". При этом разработчик должен указать следующую информацию:
- Причину возникновения дефекта.
- Место исправления, как минимум, с точностью до исправленного файла.
- Краткое описание того, что было исправлено.
- Время, затраченное на исправление.
После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".
Если проектная команда принимает решение о том, что некоторый дефект исправляться не будет, то такой дефект переводится в состояние "Postponed" с указанием лиц, ответственных за это решение, и причин его принятия.
