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

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

Основные поля баг-репорта

1. Название – краткий и конкретный заголовок найденного дефекта. Мы настоятельно рекомендуем использовать следующий шаблон: [Раздел] - Что? Где? Когда?

Пример:
[Карты] - (Что?) Операция не отображается (Где?) в истории транзакций (Когда?) после успешной оплаты

2. Шаги воспроизведения – это список действий, который описывает путь до нахождения дефекта.

1. Открыть платежное приложение.
2. Поднести устройство к терминалу (PAX S300)
3. Провести оплату с достаточным балансом
4. Проверить историю транзакций на детальной странице информации по карте

3. Фактический и ожидаемый результаты можно описать просто: “что получили, а что ожидали”.

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

В истории транзакций отсутствует информация по проведенной оплате.

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

В истории транзакций появилась информация о только что проведенной оплате.

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

Также баг-репорт содержит следующие дополнительные поля:

5. Критичность – степень серьезности влияния ошибки на работу приложения. На проектах CrowdTesting используется три типа критичности:

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

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

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

7. Повторяемость - чтобы выяснить, как часто появляется ошибка, попробуйте воспроизвести её вновь. Некоторые баги могут появиться разово, другие - воспроизводятся каждый раз.

Статусы баг-репортов

Каждому заведенному баг-репорту присваивается статус, который обновляется по мере проверки нашими менеджерами: на валидации, принят, отклонен, условно принят. 

1. На валидации - как только отчет об ошибке отправляется тестировщиком - он поступает на проверку менеджерам проекта.

2. Принят – этот статус присваивается ошибке, которая была проверена менеджером, соответствует всем правилам оформления баг-репорта, и при этом не дублирует ранее заведенные дефекты. Сам отчет направляется разработчику для дальнейшего исправления. 

3. Условно принят - баг-репорт, получивший такой статус, является дополнением к ранее заведенным принятым багам.

Баг-репорты, получившие статус “Принят” или “Условно принят” будут оплачены тестировщику по окончании проекта в зависимости от критичности ошибки.

4. Отклоненными становятся те отчеты, которые попадают под критерии: 

• дублируют ранее заведенные ошибки, 
• не являются дефектом работы приложения,
• не передают суть выявленного бага / не соответствуют правилам оформления баг-репортов.

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

Пример хорошего баг-репорта

Самое время перейти от теории к практике и подвести итоги. Мы представим пример того, как должен выглядеть хороший баг-репорт.

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

Название: [Банкомат] – На экране банкомата отображается ошибка “Операция невозможна” при попытке внесения наличных

Категория: Функциональный дефект
Критичность: Высокая
Повторяемость: Всегда

Шаги воспроизведения:
1. Открыть приложение
2. Приложить устройство к терминалу банкомата (рекомендуем указать название банка)
3. Выбрать операцию в банкомате “Внесение”.
4. Внести наличные в лоток приема.
5. Проверить окно статуса операции на экране банкомата

Фактический результат:
На экране банкомата отображается ошибка “Операция невозможна”.

Ожидаемый результат:
Операция завершена успешно, средства внесены на счет.

Скриншоты / Скринкасты:
Приложена фотография ошибки на экране банкомата. Дополнительно прикреплены фото банкомата, истории транзакций, видео процесса воспроизведения дефекта.

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

Надеемся, наш гайд поможет вам заводить хорошие баг-репорты. Присоединяйтесь к нашему сообществу, отправив заявку в телеграм-боте. Впереди еще много проектов, которые позволят на практике применить наши рекомендации. Ждем вашего участия!