Что включать в отчет об ошибке?

Как написать хороший отчет об ошибке

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

В произвольном порядке:

Идентификатор дефекта, ID

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

Резюме

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

Описание

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

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

Строгость

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

• S1 - Критическое: Это означает, что дефект представляет собой демонстрационную пробку с высоким потенциалом повреждения и не имеет обходного пути, чтобы избежать дефекта. Примером может быть приложение, которое не запускается вообще и вызывает завершение работы операционной системы. Это требует немедленного внимания, действия и исправления.
• S2 - Серьезно: Это означает, что некоторые основные функции приложений отсутствуют или не работают, и обходного пути нет. Например, приложение для просмотра изображений не может читать некоторые распространенные форматы изображений.
• S3 - Нормальный: Это означает, что некоторые основные функции не работают, но существует обходной путь, который можно использовать в качестве временного решения.
• S4 - Косметика / Улучшение: Это значит, что сбой вызывает неудобства и раздражение. Примером может быть всплывающее сообщение каждые 15 минут или вам всегда нужно дважды щелкнуть кнопку графического интерфейса, чтобы выполнить действие.
• S5 - Предложение: Обычно это не дефект и не предложение по улучшению функциональности. Это может быть графический интерфейс или настройки просмотра.

Приоритет

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

• P1 - Срочно: Означает крайне срочно и требует немедленного решения
• P2 - высокий: Требование разрешения для следующего внешнего выпуска
• P3 - Средний: Разрешение, необходимое для первого развертывания (а не для всех развертываний)
• P4 - Низкий: Решение, желаемое для первого развертывания или последующих будущих выпусков

Подробнее о важности и приоритете

Важно отметить, что дефект, который имеет высокую серьезность, также имеет высокий приоритет, то есть серьезный дефект потребует высокого приоритета, чтобы устранить проблему как можно быстрее. Не может быть дефекта высокой серьезности и низкого приоритета. Однако дефект может иметь низкую серьезность, но иметь высокий приоритет.

Например, название компании может быть неправильно написано на заставке при запуске приложения. Это не наносит серьезного ущерба окружающей среде или жизни людей, но может нанести потенциальный ущерб репутации компании и может нанести ущерб прибыли бизнеса.

Дата и время

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

Версия и сборка тестируемого программного обеспечения

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

Сообщает

Опять же, это важно, потому что, если нам может потребоваться обратиться к человеку, который поднял дефект, мы должны знать, с кем связаться.

Связанное требование

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

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

Приложения / доказательства

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

Заключение

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