Тип отчёта

В графе “Тип отчёта” указывается тип обнаруженной проблемы.

a) Ошибка кодирования. Программа ведёт себя не так, как должна, по мнению тестировщика. Например, если программа утверждает, что 2+2=3, то это явная ошибка кодирования. Программист же в ответ на отчёт о такой ошибке вполне может написать. Соответствует проекту.

b) Ошибка проектирования. Программа соответствует проектной документации, в определённом вопросе тестировщик с этой документацией не согласен. Так особенно часто случается с элементами пользовательского интерфейса. На отчёте данного типа программист не может написать Соответствует проекту, если он считает, что проект верен, тогда он пишет Не согласен с предложением.

c) Предложение. Отчёт такого типа не означает, что в программе что-то не так. В нём описывается идея, реализация которой, по мнению тестировщика, может улучшить программу.

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

e) Взаимодействие с аппаратурой. Проблемы этого рода связаны с неудачным взаимодействием программы и определённого вида аппаратного обеспечения. Если причина неудачи заключается в неисправности устройства, отчёт о ней составлять не нужно. Однако если программа не может работать ни с одной платой или устройством конкретного типа - это уже проблема, которую следует документировать.

f) Вопрос. Программа делает что-то, чего тестировщик не ожидает или не понимает. Отчёт – вопрос стоит составить при любых сомнениях. Если они окажутся основанными на действительной ошибке, программист её исправит. Если же программист откажется исправить ошибку или его объяснения не покажется вам достаточно разумным, можно будет составить отчёт об ошибке проектирования.

 

Степень важности (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

В этой графе тестировщик указывает, насколько, по его мнению, серьёзна выявленная проблема.

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

Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

 

Градация степени важности ошибки (Severity)

1 Блокирующая (Blocker)Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

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

3 Значительная (Major)Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

4 Незначительная (Minor)Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

5 Тривиальная (Trivial)Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.