Структура отчетов о проблемах, их трассировка на программный код и документацию

Структура отчёта о проблеме в целом мало различается в различных проектах, изменения обычно касаются только порядка и имен следования полей. Некоторые поля могут отражать специфику данного конкретного проекта, однако обычно эти поля следующие:

· Объект, в котором найдена проблема. Здесь помещается максимально полная информация – для документации это название документа, раздел, автор, версия. Для исходных текстов это имя модуля, имя функции/метода или номера строк, версия.

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

· Тип отчёта:

Ошибка кодирования – код не соответствует требованиям.
Ошибка проектирования – тестировщик не согласен с проектной документацией.
Предложение – у тестировщика возникла идея, как можно усовершенствовать код.
Расхождение с документацией – поведение ПО не соответствует руководству пользователя или проектной документации, или вообще нигде не описано. При этом у тестировщика нет оснований объявлять, где именно находится ошибка.
Взаимодействие с аппаратурой – неверная диагностика плохого состояния устройства, ошибка в интерфейсе с устройством.
Вопрос – тестировщик не уверен, что это проблема и ему требуется дополнительная информация.

· Степень важности. Строгого критерия определения степени важности не существует и обычно это поле кодируют от 1 (незначительно) до 10 (фатально). Однако способов обоснованной оценки нет – очень сложно определить, насколько фатальной может оказаться, например, опечатка в один символ в руководстве пользователя.

· Суть проблемы. Краткое (не более 2 строчек) определение проблемы. Даже если две проблемы очень похожи, их описания должны различаться.

· Можно ли воспроизвести проблемную ситуацию? Ответ = Да, Нет, Не всегда. Последнее – если проблема носит нерегулярный характер. Нужно описывать, когда она проявляется, а когда – нет (например, не вовремя нажать не ту клавишу).

· Подробное описание проблемы и способ её воспроизведения. При этом нужны подробности – и в описании условий воспроизведения, и в описании причины объявления получившейся реакции ошибкой.

Обычный вид отчета о проблеме, соответствующего данной структуре, следующий:

Отчёт о проблеме

Порядковый номер отчёта:

Автор отчёта: ___________________ Дата создания отчёта: __ __ __

Документы/разделы, связанные с проблемой:

……………………………………..

Идентификация объекта/процесса, где проявляется проблема:

………………………………………………………………………………………….

Определение проблемы:

………………………………………………………………………………………….

Автор решения: ___________________ Дата формирования решения __ __ __

Принятое решение: (возможно, ссылки на изменяемые компоненты/запросы на изменения)