Обоснование

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

Краткое описание Описание проблемы на кон­

проблемы цептуальном уровне. Обычно

такое описание дефекта уме­

щается в одной строке.

Описание Детальное описание симпто­

проблемы мов проблемы и того, как она

ограничивает функциональные

возможности или производи­

тельность системы.

Степень Упорядочивание дефектов по

серьезности степени серьезности послед­

дефекта ствий. Примеры:

Катастрофический - вызыва­

ет разрушение системы

Крупный - программный про­

дукт не подлежит использова­

нию

Умеренный - продукт можно

использовать, однако имеют

место некоторые неудобства

для пользователя

Незначительный - пользова­

тель не ощущает последствий

Помеха - можно устранить,

когда позволит время.

Как воспроизвести Используется детально прора­

проблему ботанная методика воспроиз­

ведения проблемы, включая

выбор используемой конфигу­

рации средств тестирования.

Может оказаться достаточным

сказать: " Выполнить прогон

теста с идентификатором та­

ким-то", если этот тест хорошо

документирован.

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

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

Серьезность последствий часто опреде­ ляет приоритеты усилий разработчиков при устранении дефектов и тестировщи-ков при проверке результатов этих ис­ правлений.

Детально проработанная методика по­ зволяет разработчикам воспроизвести дефект и предоставляет возможность разработчикам и тестировщикам прове­ рять результаты устранения проблемы.

Каждый дефект получает в базе данных отслеживания дефектов уникальный идентификатор, так называемый идентификатор дефекта. Идентификатор дефектов представляет собой ключ, который поддерживает запросы, поступающие в базу дан­ ных с таким расчетом, чтобы можно было получить информацию о его состоянии, которое можно рассматривать как показатель продвижения работ по его устранению. В базе данных отслеживания дефектов должны храниться сведения о том, кто обна­ ружил дефект, когда он был обнаружен, уровень серьезность дефекта, а также под­ робное описание проблем, которые он вызвал. Если дефект был обнаружен во время системных испытаний, должна быть записана информация, касающаяся теста, кото­ рый выявил этот дефект. Для хорошо документированного тестового случая вполне достаточно запомнить только идентификатор теста. Если тест не задокументирован должным образом или если дефект был обнаружен в результате специализированного (ad hoc) тестирования, необходимо записать информацию о конфигурации средствтестирования и о специальных действиях, выполненных для обнаружения этого де­ фекта. Пример отчета о дефекте, который может использоваться для целей докумен­ тирования, приводится далее в разделе " Как составлять сообщения о дефектах".

Данные о дефекте, попадающие в базу данных отслеживания дефектов, должны быть изучены группой анализа обнаруженных дефектов (или группой контроля за внесением изменений) с целью определения степени серьезности дефекта. На самом ли деле это дефект? Правильная ли степень серьезности была присвоена обнаружен­ ному дефекту? Должен ли он быть устранен в текущем выпуске программного продук­ та? Информация, которая должна быть внесена в базу данных отслеживания дефек­ тов по результатам работы группы анализа дефектов, показана в таблице 5.3. В ре­ зультате анализа дефект переводится в одно из следующих трех состояний:

• Исправить (fix) — дефект переходит в это состояние, если группа анализа ре­шит, что данных дефект должен быть исправлен в текущем выпуске.

• Отложить (defer) — дефект переводится в это состояние, если группа анализарешит отложить устранение этого дефекта до последующих выпусков про­ граммного продукта.

• Игнорировать (trash) — дефект переходит в это состояние, если группа анали­за решила, что дефект был внесен по ошибке.

В зависимости от итогового состояния дефекта, в базу данных отслеживания де­ фектов вводятся различные данные. Например, если дефект двигается в направлении состояния " исправить", следует ввести имя исполнителя, ответственного за устране­ ние дефекта. Если информация относительно дефекта готовится для передачи заказ­ чикам, должен быть введен текст пояснительной записки по выпуску. Более подроб­ ная информация, касающаяся анализа дефектов, будет изложена в разделе " Анализ дефектов".

Как показано в таблице 5.4, окончательный набор данных нужно вводить в систе­ му отслеживания дефектов во время исправления дефекта. Необходимо зафиксиро­ вать имя исполнителя, исправляющего дефект, дату исправления и идентификатор сборки, в которой производилось исправление. Должно быть дано подробное объяс­ нение основной причины проблемы, чтобы группа разработки могла воспроизвести и устранить проблему.

126 Часть I. Процесс быстрого тестирования

Таблица 5.3. Данные отслеживания дефекта в состояниях " исправить" (fix), " отложить" (defer) и " игнорировать" (trash)