Задача тестировщиков программного обеспечения — изучить работу ПО и выявить несоответствия между ожидаемым поведением, которое указано в требованиях, и реальным поведением ПО в каждом из сценариев использования. В случае если тестировщик находит ошибку в работе в ПО, он пишет специальный отчет об ошибке, чтобы рассказать о нем коллегам, — баг-репорт. Когда коллеги или другие заинтересованные лица изучат баг-репорт, они поймут, в чем дело. Баг-репорт оформляется в специальной системе для отслеживания ошибок — баг-трекере. Каждая команда или компания сама решает, каким именно баг-трекером пользоваться. Теперь перейдем к собственно сути баг-репорта, его составляющих и правилах оформления.
Баг-репорт включает обязательные и необязательные элементы.
Обязательные поля:
- ID — идентификационный номер баг-репорта, должен быть уникальным. Помогает быстро найти нужный баг-репорт.
- Заголовок — передает суть ошибки; помогает быстро понять, в чем дело.
- Шаги воспроизведения — пошаговая инструкция о том, как воспроизвести ошибку.
- Результаты — описание фактического результата и ожидаемого результата.
- Окружение — операционная система, браузер, устройство (в случае мобильного приложения), версия приложения.
- Приоритет — показывает степень критичность ошибки и срочность ее исправления.
Необязательные поля:
- Предусловие — описывает, как систему нужно подготовить перед тестированием (в случае необходимости).
- Постусловие — указывает, как систему нужно вернуть в прежний вид после тестирования (в случае необходимости).
- Описание — прописывают, если в заголовке передано недостаточно информации об ошибке.
- Дополнительные материалы — прикладываются в случае необходимости и помогают проиллюстрировать ошибку (скриншот, скринкаст).
Пример правильно составленного баг-репорта:
Теперь давайте поговорим о каждом пункте немного детальнее.
Заголовок баг-репорта
Задача заголовка — в достаточной мере описать суть проблемы. Грамотно написанный заголовок помогает коллегами сразу понять суть, не тратя время на прочтение всего баг-репорта целиком. Заголовок должен отвечать на три вопроса: «Что? Где? Когда?», при этом не должен быть слишком длинным. Заголовок должен отражать реальный результат.
Примеры удачных заголовков:
- Клик по слову «Регистрация» на странице подписки приводит к ошибке 400.
- При переходе по ссылке «Заказ» на главной странице экрана открывается страница Контакты вместо страницы Мои заказы.
Шаги
В этом пункте прописывается алгоритм действий, которые должны привести к описываемой ошибке. Действия должны быть описаны достаточно полно, но емко, и быть понятными для любого человека вне зависимости от технической подготовки, который попытается воспроизвести ошибку. После написания шагов хорошей практикой будет еще раз пройтись по этому алгоритму, чтобы убедиться, что алгоритм понятен и что ошибка по нему воспроизводится.
Приоритет и серьезность
Приоритет (priority) отражает степень важности проблемы и срочность выполнения задачи, включает 3 уровня:
- Высокий (high) — необходимо исправить в первую очередь, так как с данной ошибкой продукт не выполняет свой бизнес-задачи: например, не работает кнопка заказа в интернет-магазине.
- Средний (medium) — ошибка менее критичная, пользователь может достигнуть цели, однако ПО работает не так, как от него ожидается. Например, в корзине интернет-магазина не отображается блок сопутствующих товаров.
- Низкий (low) — не мешает пользователю достигнуть цели, можно починить после критических ошибок. Например, опечатки в тексте.
Серьезность (severity) показывает степень влияния на работу системы.
- Блокирующий (blocker) — программа не работает. Например, сайт выдает ошибку 500.
- Критический (critical) — не работает важная часть системы, приложение не выполняет своей функции. Например, невозможно добавить товар в корзину незарегистрированному пользователю.
- Серьезный (major) — приложение работает, функциональность не пострадала, однако работает некорректно. Например, не позволяет пользователю выбрать марку авто в приложении по заказу такси.
- Незначительный (minor) — приложение работает правильно, но вызывает какие-либо неудобства. Сюда можно отнести ошибки навигации и другие ошибки UX-характера.
- Тривиальный (trivial) — ошибка, которая не оказывает никакого влияния на работу приложения. Например, опечатки в тексте.
Окружение
В этом пункте описывается среда, в которой произошла ошибка. Операционная система и ее версия, браузер и его версия, версия приложения, размер экрана (если необходимо). Если ошибка произошла на мобильном устройстве, также указывается тип устройства и его модель.
Вложения (вспомогательные материалы)
Помогают дополнить информацию о проблеме, визуализируют ошибку. К баг-репорту можно прикрепить:
- Скриншоты и скринкасты
- Логи, дампы
- Переписки
- Документацию
Не забывайте давать вложениям понятные названия. Можно использовать маску {ID баг-репорта}_{суть ошибки}.
Чтобы прокачаться в тестировании и научиться находить самые каверзные баги, приходите учиться в OTUS.
