Принципы написания Bug report. Десять принципов создания эффективных отчетов по дефектам (Bug Report)

Название	Десять принципов создания эффективных отчетов по дефектам (Bug Report)
Дата	24.12.2018
Размер	22.77 Kb.
Формат файла
Имя файла	Принципы написания Bug report.docx
Тип	Документы #61638

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

Корректно и грамотно написанный отчет, безусловно, помогает тестеру получить необходимый feedback от разработчиков намного быстрее.

Хороший тестер это не тот, кто стремится написать идеальный отчет по дефектам, а тот, кто стремится писать отчет, основываясь на следующих четырех простых атрибутов:

Атрибут-1: Он должен быть эффективным

Атрибут-2: Он должен содержать адекватное описание

Атрибут-3: Он должен быть достаточным, чтобы провести необходимую работу для устранения дефектов.

Атрибут-4: Он должен быть способен упростить процесс для всех заинтересованных сторон (должен быть написан просто, грамотно и корректно)
Существует Десять Основных Принципов, которые призваны помочь в описании отчета по дефектам. Их главным результатом является осуществление "Атрибут - 1":

Описание должно быть коротким, описывающим самую суть.

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

Необходимо помнить, что чем больше неактуальной, тем меньше полезной и тем сложнее работать с таким отчетом.

Должны быть точно определены: Описываются только реальные ошибки. Необходимо следить за тем, чтобы не были пропущены дефекты.

Используете следующие правила, которые могут быть полезными при составлении отчета по дефектам (описании проблем).

а) Используется не только в написании отчета.

б) Всегда сообщайте о найденных ошибках. Будьте смелее.

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

г) Вы всегда можете проконсультироваться с другим тестером или даже разработчиком, если вы сомневаетесь по поводу правильности или корректности найденной ошибки

Следующие утверждения могут быть полезны при описании проблемы:

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

Будьте объективными: проблема должна быть определена объективно с учетом всех требований и ее описания.

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

Опишите проблему точно и недвусмысленно

Вместо простого описание того, лучше указать что конкретно получить на практике. Необходимо стараться описать проблему четко и явно.

Следующие советы могут быть полезными при описании проблемы:

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

Изолировать проблемы: необходимо применять большое количество усилий, чтобы изолировать проблему.

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

Обобщить задачу: необходимо определить важность проблемы в работе ПО.

В зависимости от этого можно более грамотно составить описание проблемы.

Определить необходимые, воспроизведения дефекта.

Если по каким либо причинам дефект воспроизводится в хаотичном порядке, то необходимо более полное описание дефекта, для того, чтобы разработчик разобрался с данной проблемой.

При воссоздании шагов воспроизведения дефекта, необходимо полностью указывать все шаги, необходимые имена файлом, путь, синтаксис и т.д.

Иногда следует приглашать разработчиков к себе, с целью показать поведение ПО на конкретном компьютеру.

Определение результатов дефекта на стороне клиента.

В зависимости от того, какой контингент и с какими профессиональными навыками будет работать с ПО, необходимо рассмотрение вопроса об исправлении. Не всегда необходима целесообразность исправления дефекта (если он конечно не Critical), если с данной часть По работать никто не будет (или она будет недоступна)

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

Информация для отладки.

Для более полного понимания дефекта можно к описанию его приложить различные фалы типа logs, dumps, traces и так далее

Предоставить необходимую сопроводительную документацию.

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