Баг-репорт (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?);

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

  • Проиллюстрируйте проблему с помощью правильных скриншотов, видео и логов;

  • Перед отправкой перепроверьте ваш отчет об ошибке. А потом еще раз;

Источники:

Доп. материал:

PreviousЧек-лист (Check List)NextТребования (Requirements)

Last updated