Требования к bug report

Bug report — документ или отчёт, содержащий информацию о дефектах в ПО/Web-сайте.

В данной статье:

• Описаны самые важные разделы, которые должен содержать bug report (БР). Разделы, которые не раскрыты, требуют отдельных статей (например, Severity & Priority), не требуют пояснений, либо редко используются.
• Названия полей и примеры написаны на английском языке и взяты из тестирования публичных сайтов через utest. Английский язык используется в международных площадках для тестировщиков или в компаниях, имеющих outsource работников.
• Примеры из внутренней части ПО не будут приведены из-за NDA.
• Примеры и объяснения относятся к веб-сайтам, а не программам.

Summary

Заголовок должен кратко изложить суть возникшего дефекта, чтобы человек, читающий БР, уловил главную идею. В идеале, он не должен читать весь БР, чтобы понять дефект. В первую очередь заголовок должен содержать описание того, на что повлиял дефект (функциональность, UI и т. д.). Опишите, что произошло, а не то что должно было произойти (Expected Result), поскольку пользователь может и не знать, какой именно должен быть ожидаемый результат.

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

Примеры заголовков:

• Неправильно: The credit card field is not working.
• Корректно: The user can add credit cards with only 13–16 digit numbers — i.e., Nothing happens after trying to enter the 17th digit.

Pre-Conditions

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

Steps to reproduce

Поскольку человек, который читает БР, должен воспроизвести дефект, то тестировщик должен предоставить пошаговую инструкцию по его воспроизведению. Все шаги описывают только ключевые действия (шаг начинается с глагола).

Нельзя пропускать шаги, которые необходимы. Первый шаг описывает модуль приложения, с которого нужно начать, чтобы воспроизвести дефект. Например, авторизоваться на сайте. Последний шаг описывает действие, непосредственно вызывающее сам дефект (Actual Result).

Если на каком-то шаге требуются конкретные входные параметры, следует их указать. Например, номер количество символов в поле , тип аккаунта и т. д.

Например:

• Insert any valid email via the clipboard (e.g., email@domain.com)
• Enter/paste a valid credit card number (e.g., 4195918755568250)
• Enter/paste a website URL with any subdirectory/file (e.g., https://www.netflix.com/ru/browse/genre/839338)

Если требуется наглядность результата определённого шага, то можно указать ожидаемый результат одного шага с помощью символа стрелки “>”.

Например:

• Choose ‘10+’ in a drop-down list > A text field is available
• Click on the article link (e.g., “Here’s What’s Happening With Elon Musk’s Twitter Picture” — https://www.forbes.com/sites/davidthier/2020/05/02/heres-whats-happening-with-elon-musks-twitter-picture/#6285febf50da)
• Choose 6 items > Quantity is not available

Один шаг не может содержать несколько действий. Если это так, то следует разделить этот шаг на 2 шага. Нельзя писать “Click on the “Privacy Statement” link in the footer bar and select any language from the drop down list (e.g., German)’”. Следует отделить шаги на Click on … и Select …

Пример Test Steps:

1. Log in on [URL]
2. Add some products to cart
3. Click/tap on the “CHECKOUT” in Cart
4. Enter or paste a valid 19-digit Discover card number (e. g., 6011534731765854969)
5. Change any payment method

Expected Result

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

• Неправильно: The counter is working correctly.
• Корректно: After clicking on the “Plus” button, the item quantity inside the product counter increases by one.

Actual Result

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

Ожидаемый и фактический результат не должны сильно пересекаться друг с другом. Нужно убедиться, что информация в этих разделах не похожа. Грубо говоря, нельзя писать в Actual Result “Ничего работает”, а в Expected Result “Всё работает”.

• Неправильно: The counter is not working correctly.
• Корректно: After clicking on the “Plus” button, the item quantity is multiplied by 2.

Environment

Название среды, где был найден дефект. Чаще всего это операционная система и браузер.

Например:

1. Windows 10 Pro, Firefox 101.0 (64-bit)
2. macOS 10.13.6, Safari 10
3. iOS 15.5, Firefox 100.1 (9384)

Attachments

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

Некоторые виды прилагаемых файлов:

• Screenshots. Прикрепляется в JPG или PNG формате. Обычно это ошибки в дизайне или содержимом сайта. Выделите дефект среди всех остальных элементов приложения. Используйте приложения для снимков экрана, чтобы было проще отредактировать изображение (обрезать ненужные части, выделить дефект и т. д.). При обрезке дефекта следует оставить текущую дату, но убрать лишние или пустые области.
• Screencasts. Прикрепляется в том случае, когда нужно показать определённую последовательность шагов, либо, когда этих шагов достаточно много. Прикрепляется в MP4 формате и длится 10–60 секунд. Перемещения курсора, клики или нажатия (для мобильных устройств) должны быть выделены. Во время воспроизведения дефекта видеофайл не должен останавливаться посередине или быть вырезанным (все шаги выполняются последовательно).
• Log files (Server/Client). В случае сбоев, зависаний или любой другой критической функциональной проблемы, логи являются обязательными в качестве ключевого компонента БР.
• User guide. Если в приложении есть несоответствие требованиям, то следует указать техническую документацию, которая доказывает наличие дефекта. Например, отсутствие нужных столбцов в таблице или ограничение для полей.

Опциональные поля

Поля, которые есть или нет в зависимости от компании или баг-трекинговой системы.

Product: Название проекта/ПО/сайта.

Defect ID: Автоматически генерируемый ID баг-трекинговой программой.

Area/Path: Тестируемый компонент.

Build Number: Номер сборки.

Version: Версия ПО.

Component: Подмодуль.

Severity: High (High/Medium/Low) or 1. Определяет влияние дефекта на продукт. Выставляется тестировщиком.

Priority: High (High/Medium/Low) or 1. Как скоро дефект должен быть исправлен. Обычно с P1 (наивысший) до P5 (не срочный). Выставляется PM или тестировщиком.

Assigned to: На кого назначено исправление дефекта.

Reported By/Defect Reporter: Ваше имя.

Reported On: Дата обнаружения дефекта.

Reason: Дефект/предложение по улучшению. Зависит от используемой баг-трекинговой программы.

Status: Новый/Открыт/Активный/Исправлен/Не баг/Переоткрыт/Не будет исправлен. Зависит от используемой баг-трекинговой программы.

Description: Детали по публикуемому дефекту.

URL: Страница, на которой был обнаружен дефект.

Summary: Краткое описание дефекта длиной в 60 символов. Отражает суть дефекта.

Типы дефектов

1. Функциональные,
2. Дизайн,
3. Контент,
4. UX,
5. Производительности,
6. Безопасности,
7. Ошибка в коммуникации,
8. Ошибка в коде (синтаксис, логика),
9. Проблема документации.

Хороший баг-репорт

• Содержит всю информацию для воспроизведения дефекта.
• Явно доносит всю суть дефекта до разработчика.
• Опубликован немедленно
• Направлен конкретному разработчику.
• Составлен по стандарту компании

Плохой баг-репорт

• Длинный и содержащий избыточную бесполезную информацию.
• Имеет незаполненные обязательные поля.
• Не имеет специфическую информацию.

Заключение

1. Воспроизведите дефект 2–3 раза, чтобы убедиться в том, что он действительно существует.
2. Публикуйте bug report как можно быстрее. Если вы нашли дефект, то не ждите время, чтобы дополнить БР позже. Из-за этого можно забыть некоторые детали или потерять время.
3. Ищите потенциальный дефект на других схожих модулях приложения. Есть вероятность, что найденный дефект воспроизводиться и в других частях приложения. Иногда разработчик использует похожий программный код в аналогичных модулях.
4. Правильно донесите всю необходимую информацию. Хороший БР помогает разработчику быстро понять суть дефекта.
5. Заголовок явно объясняет, в чём заключается дефект. Используйте только самую необходимую информацию.
6. Используйте формальный стиль написания. Описывайте всю информацию в БР в формальном стиле. Не используйте сленг или упрёки в сторону разработчика.
7. Предоставьте полный набор доказательств (Attachments), чтобы разработчик не задавал дополнительных вопросов.
8. Перепроверьте bug report. Перед публикацией БР прочитайте его ещё раз и убедитесь, что главные моменты описаны по всем требованиям.

Обязательные поля:

1. Summary,
2. Pre-Conditions,
3. Steps to reproduce,
4. Environment,
5. Expected и actual results,
6. Attachments.

Источники

1. Bug Report Requirements
2. https://www.utest.com/articles/bug-monitoring-tracking-tips-to-write-a-good-bug-report
3. Shinde V. Software Testing Career Package: A Software Tester’s Journey From Getting A Job To Becoming A Test Leader! Software Testing Help, 2015.
4. Types of Bugs in Software Testing
5. What is a bug report? The ins and outs of bug reports.