После нахождения дефекта в процессе проверки функциональности на соответствие требований необходимо составить отчет, для исправления разработчиком ошибки.
Отчет о дефекте, или bug report - документ, описывающий ситуацию, которая привела к обнаружению дефекта, с указанием причин и ожидаемого результата.
Это запись или задача с типом "Ошибка / Дефект / Bug report".
Цели создания дефекта
- Предоставить информацию о проблеме
- Определить приоритеты проблемы
- Содействовать устранению дефекта
Как только вы нашли дефект необходимо сообщить об этом команде и указать насколько приоритетно его устранение и в дальнейшем реализация продукта с его наличием. Разработчику для устранения дефекта важно знать все о нем: при каких условиях нашли, где нашли и как можно его воспроизвести. Если разработчик не сможет повторить на своей среде ошибку, он придет к вам за разъяснениями.
Для фиксации дефекта требуется баг-трекинговая система.
Пожалуй, одна из самых распространенных баг-трекинговых систем - Jira. В ней можно не только заводить дефекты, но и писать тестовое покрытие и связывать задачи с тест-кейсами. Она имеет еще много плюшек, на которых я не буду заострять внимание.
Люблю ее всем сердцем.
Что необходимо указать в задаче о дефекте
- Тип
Ошибка / Дефект / Bug report
- Тема
Кратко зафиксировать в чем ошибка. Взяла за правило указывать название, отвечая на вопросы "Что? Где? Когда?".
- Описание
Здесь надо заполнить:
- Предусловия - действия, которые необходимо сделать перед началом прохождения пользовательской истории.
- Шаги воспроизведения - это ваши последующие действия для воспроизведения фактического результата. Лучше так же кратко, без лишней воды. Разграничивайте каждый шаг, чтоб разработчику было удобнее читать и воспринимать информацию.
- Фактический результат - поведение в системе, полученное в момент тестирования. Необходимо стараться описывать информативно (придерживаюсь правила ответа на вопросы "Что? Где? Когда?")
- Ожидаемый результат - поведение в системе, которое мы можем взять из требований. Описание аналогично с фактическим.
- Файлы, при наличии
Это могут быть скрины экранов, записанное видео с воспроизведением дефекта или файлы логов.
- Срок устранения ошибки, если требуется.
- Человека, который будет устранять дефект
Обычно указывается разработчик, который делал эту функциональность.
- Нашедшего дефект
Себя, как того кто нашел дефект.
- Серьезность дефекта (важность)
Это атрибут ошибки, характеризующий влияние дефекта на работоспособность продукта.
- Приоритет, т.е. насколько срочно необходимо выполнить задачу по устранению дефекта.
Например:
Если вы тестируете форму авторизации книжного магазина и не можете авторизоваться, то приоритет такого дефекта будет блокирующим или критичным. Из-за ошибки вы не сможете купить книгу, как авторизованный пользователь.
Если вы тестируете форму поиска книжного магазина и не можете найти товар через поиск, то такой дефект можно с натяжкой считать отнести к ошибкам со средним приоритетом. У вас же не пропала возможность перехода в нужный раздел, выбора нужного товара и добавление его в корзину.
Тестировщик должен не только завести дефект, но и следить за ходом его устранения. Как только разработчик его исправит и это попадет в сборку, надо приступать к ретесту (перепроверке воспроизведения).
Если все исправлено, то закрываем с соответствующим комментарием.
Если не исправлено, то возвращаем обратно разработчику с комментарием, о том что до сих пор воспроизводится ошибка.
Каждый дефект имеет свой жизненный цикл. Его можно более подробно рассмотреть на картинке ниже.
