Bug Report
Bug Report
Баг-репорт (Defect/bug report)
Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. (IEEE 829)
«Смысл написания отчета о проблеме (отчета об ошибке) состоит в том, чтобы исправить ошибки» - Джем Канер. Если тестировщик неправильно сообщает об ошибке, то программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима. Или потратит кучу лишнего времени на то, чтобы сделать вашу работу за вас. Едва ли такой тестировщик будет выгоден бизнесу, приятен коллегам и долго задержится на своем месте.
Главное при написании отчета - он должен быть сразу и однозначно понят читающим, а дефект однозначно воспроизведен по указанным шагам в указанном окружении.
Основные поля баг-репорта:
- Уникальный идентификатор (ID);
- Описание (Summary): краткое, емкое и понятное описание ошибки;
- Окружение (Environment): ссылка на билд/коммит/версия ПО и всего окружения;
- Шаги воспроизведения (Steps to reproduce): полный перечень шагов для воспроизведения;
- Ожидаемый результат (Expected result): какой результат должен был быть без ошибки;
- Фактический результат (Actual result): какой результат получился на самом деле;
- Вложения (Attachments): логи, скриншоты, видео - всё что необходимо для понимания ошибки.
Дополнительные:
- Предварительные условия (Prerequisites);
- Тестовые данные (Test Data);
- Серьезность дефекта (Defect Severity);
- Комментарии (Remarks);
- Проект (Project);
- Продукт (Product);
- Версия релиза (Release Version);
- Модуль (Module);
- Обнаружено в версии (Detected Build Version);
- Вероятность возникновения дефекта (Defect Probability);
- Приоритет дефекта (Defect Priority);
- Автор отчета (Reported By);
- Назначено на (Assigned To);
- Статус (Status);
- Fixed Build Version.
В случаях использования TMS поля будут настроены лидом/менеджером и в зависимости от размеров проекта могут быть пункты вроде milestone, epic, feature и т.п.
Помимо прочего, баг-репорты могут создаваться не только тестировщиками, но и любыми членами команды, приходить от пользователей или техподдержки. Во втором случае необходимо будет воспроизвести ошибку, составить баг-репорт по всем правилам или дополнить присланный, затем провести ретроспективу на тему того, как ошибка попала в прод и как этого избежать в будущем.
Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке:
- В одном отчете один баг;
- Воспроизведите его 2-3 раза;
- Убедитесь, что используете актуальную версию ПО и окружения;
- Проверьте по поиску багтрекинговой системы наличие отчета о таком же дефекте;
- Локализуйте ошибку, чтобы выяснить ее первопричину;
- Напишите подробные шаги и полное окружение для воспроизведения ошибки;
- Напишите хорошее summary дефекта по формуле “Что? Где? При каких условиях?” (3 Ws, WWW - What? Where? When?);
- Следите за словами в процессе написания сообщения об ошибке, они не должны обвинять, оскорблять людей, содержать какую-либо точку зрения по поводу произошедшего. В общем, только факты по делу;
- Проиллюстрируйте проблему с помощью правильных скриншотов, видео и логов;
- Перед отправкой перепроверьте ваш отчет об ошибке. А потом еще раз;
Источники:
Доп. материал:
- Defect Probability
- Не пишите в баге «Ввести 6,9»!
- Воспроизводится ли баг по твоим шагам? Проверь!
- Нужна авторизация? Дай данные
- Эмоций в баге быть не должно!
- 4 типичные ошибки оформления бага новичком
- Шаблон бага
- О записи багов, или Найди кота
Отчет о дефекте
Отчет о дефекте / Баг Репорт (Bug Report)
Документирование возникновения, характера и состояния дефекта. [Глоссарий ISTQB]
Включает описание ситуации или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Состав баг репорта
| Поле | Описание |
|---|---|
| Заголовок (Summary) | Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. |
| Проект (Project) | Название тестируемого проекта |
| Компонент приложения (Component) | Название части или функции тестируемого продукта |
| Номер версии (Version) | Версия на которой была найдена ошибка |
| Критичность (Severity) | Наиболее распространена пятиуровневая система градации серьезности дефекта: • S1 Блокирующий (Blocker) • S2 Критический (Critical) • S3 Значительный (Major) • S4 Незначительный (Minor) • S5 Тривиальный (Trivial) |
| Приоритет (Priority) | Приоритет дефекта: • P1 Высокий (High) • P2 Средний (Medium) • P3 Низкий (Low) |
| Статус (Status) | Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например: • Новый • Открыт • Закрыт |
| Автор (Author) | Создатель баг репорта |
| Назначен на (Assigned To) | Имя сотрудника, назначенного на решение проблемы |
| Описание (Description) | Окружение (Environment): Информация об окружении, на котором был найден баг. Операционная Система, Service Pack; для WEB тестирования — имя и версия браузера и т.д. Шаги воспроизведения (Steps to Reproduce): Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Фактический Результат (Actual Result): Результат, полученный после прохождения шагов к воспроизведению. Ожидаемый результат (Expected Result): Ожидаемый правильный результат |
| Дополнения | Прикрепленный файл (Attachment): Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы |
Дополнительные ссылки
Как написать хороший баг репорт
https://www.softwaretestinghelp.com/how-to-write-good-bug-report/
https://testlio.com/blog/the-ideal-bug-report/
https://testit.software/blog/post/kak-pravilno-oformit-bag-report