Аудит от независимых экспертов

поможет выявить проблемы на вашем сайте


 

 
 
 

Как правильно писать сообщения об ошибках?

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


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

Баг-репорт в обязательном порядке должен содержать: 

1. Однозначное указание на номер сборки, в которой данный дефект обнаружен. 
Обычно этот номер пишется в квадратных скобках перед темой, например: 
[0.0.1-Программа_Тест]: отсутствует отчет по мониторингу качества. 
Если номер сборки установить невозможно или дефект обнаружен в результате тестирования на постоянном стенде (или площадке заказчика) допускается вместо номера сборки указывать однозначный идентификатор (ip-адрес, dns-имя) машины, на которой обнаружен дефект, например: 
[192.168.1.2-Программа_Тест]: отсутствует отчет по мониторингу качества. 

2. Наименование дефекта (тема, заголовок). 
Указывается после номера сборки или идентификатора машины (см. п.1). Заголовок должен однозначно и максимально идентифицировать дефект. 
Пример неудачного описания: 
[192.168.1.2-Программа_Тест]: не работает кнопка. 
Из приведенной информации неясно, какая кнопка не работает, как именно она не работает и где она находится. 
Пример корректного описания: 
[192.168.1.2-Программа_Тест]: exception при нажатии кнопки «Выход из системы». 
Данная информация содержит полную и однозначную информацию о сущности выявленного дефекта. 

3. Компонент (пакет), в котором предположительно выявлена проблема.
Ключевое слово – «предположительно» (обнаружив дефект в интерфейсе, без должного исследования невозможно утверждать, что ошибка возникает именно на стороне клиента, а не сервера). Обнаруживший дефект делает предположение, а окончательный вердикт выносится разработчиками.
 

4. Степень критичности дефекта. 
При определении степени критичности дефекта допустимо использование двух подходов: 
1) Точка зрения заказчика: степень влияния на функционал, участвующий в бизнес-процессах: 
• blocker/critical – не работает базовый функционал, описанный в техническом задании, ведение бизнес-процессов невозможно. 
• normal – базовый функционал работает, но не так, как задумано, ведение бизнес-процессов возможно. 
• minor/trivial – опечатки, юзабилити и др. 
• enhancement – пожелания по улучшению, не указанные явным образом в техническом задании. 
2) Точка зрения тестировщика: степень влияния на общую работу приложения: 
• blocker/critical – не работает базовый функционал, описанный в техническом задании, продолжение тестирования невозможно или бессмысленно. 
• normal – базовый функционал работает, но не так, как задумано, продолжения тестирования возможно. 
• minor/trivial – опечатки, юзабилити и др. 
• enhancement – пожелания по улучшению и доведению приложения «до ума» 
По сути дела, оба подхода однозначно классифицируют один и тот же дефект. 

5. Краткое описание проблемы.
Фактически повторяет заголовок, но содержит некоторую детализацию.
 
Пример неудачного описания: 
Не работает кнопка, нельзя выйти из приложения. 
Пример корректного описания: 
При нажатии кнопки «Выход из системы» в модальном окне показывается exception следующего содержания: <…>. В результате не происходит разлогинивание пользователя. 

6. Описание последовательности действий, приведшей к обнаружению дефекта.
Необходимо описать всю последовательность действий, назвать роль пользователя, привести иную информацию, позволяющую пошагово воспроизвести ошибку.
 
Пример неудачного описания: 
Нажать кнопку «Выход». 
Пример корректного описания: 
1) Логин в систему в роли оператора. 
2) Перейти на вкладку «Мониторинг». 
3) Нажать кнопку «Выход из системы» в правом верхнем фрейме. 

7. Описание ожидаемого результата. 
Поскольку иногда представления о том или ином функционале системы различаются (разработка и тестирование, разработка и заказчик, разработка и аналитик) требуется однозначное указание ожидаемого результата. 
Пример: 
Разлогинивание пользователя, завершение работы приложения. 

8. Описание полученного результата. 
Пример неудачного описания: 
Кнопка «Выход» не работает. 
Пример корректного описания: 
Выдается exception в модальном окне, не происходит разлогинивания пользователя, не происходит завершения работы приложения. 

9. Воспроизводится ли ошибка? 
Достаточно простого ответа Да/Нет. Необходимо разработчикам для планирования времени на устранение: плавающие ошибки отлавливать намного сложнее. Если известны особые условия, в которых ошибка воспроизводится, их нужно указать. 

10. Возможные последствия дефекта. 
Здесь могут быть указаны все предположительные последствия, в том числе: проблемы на поддержке, необходимость документирования тех или иных особенностей, необходимость изменения архитектуры и т.д. Ключевым словом также является слово «предположительно», окончательная верификация принадлежит разработчикам. 

11. Дополнительная информация. 
Логи, журналы, содержимое конфигурационных файлов, скриншоты экрана – все, что может облегчить воспроизведение и устранение ошибки.

 
Голосов: 3
Баллы рейтинга: 15

AncicPah пишет:
07.06.2017 20:01
Ну в принципе все по делу<a href=http://agrolinepro.ru/packing-lines>.</a>
NewmcPah пишет:
05.08.2017 20:52
Thanks<a href=http://forums.eog.com/showthread.php/379858-Heavyweight-Boxing-Ortiz-vs-Jennings-is-Saturday>.</a>
sanhvcPah пишет:
13.09.2017 11:27
[url=http://www.sbup.com/seo-forum/registraciya/200_otkrytyh_ankornyh_ssylok_vsego_za_100_rublei/]анкорные ссылки[/url]
engladPah пишет:
16.01.2018 23:36
Попробую также[url=http://pt.educationinuk.ru/karta-sajta]:)[/url]