Атрибуты отчёта о дефекте. Часть 1.

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

Основные атрибуты отчёта о дефекте

В первую очередь давайте кратко разберёмся из чего состоит отчёт о дефекте. Данные пункты помогают легче структурировать каждую найденную проблему и подгонять под единый формат.

1. Заголовок (Summary) - название бага, которое отражает суть проблемы.
2. Описание (Description) - иногда требуется более детально описать баг. Бывает недостаточно просто указать последовательность шагов.
3. Шаги для воспроизведения (Steps To Reproduce) - последовательность действий, чтобы воспроизвести баг.
4. Фактический результат (Actual result) - то как ведёт себя система на самом деле.
5. Ожидаемый результат (Expected result) - то как система должна себя вести, согласно документации.
6. Серьёзность дефекта (важность, Severity) - показывает на сколько сильно дефект задевает систему. Бывает такое что один незначительный баг, перекрывает очень важный функционал.
7. Приоритет дефекта (срочность, Priority) - указывает на очередность исправления дефекта. Чем он выше, тем быстрее нужно исправить.
8. Статус (Status) - в процессе разработки у бага может меняться статус. Он может стать снова актуальным.
9. Тестовое окружение - возможно указывается версия релиза, версия браузера, так как баг может встречаться не на всех версиях.
10. Вложения - это всевозможные скрины, файлы, которые помогают в изучении бага

Заголовок отчёта о дефекте

Заголовок отчёта о дефекте играет ключевую роль, поскольку он должен кратко и точно описывать суть проблемы. Хороший заголовок должен быть информативным, понятным и легко воспринимаемым.

Основное правило, которые вы должны для себя сформулировать это то как составляется Заголовок. При любой возникшей проблеме последовательно отвечайте на вопросы «Что? Где? Когда?».

Составленный таким образом заголовок всегда будет полноценным и понятным для любого читателя.

Примеры

К примеру у нас есть сервис для покупки товаров. Мы можем выбрать товар, начать его покупать, но он не добавляется в корзину.

Плохой пример - товар не добавляется в корзину.

В таком случае появляется множество вопросов:

• Почему товар должен попадать в корзину?
• Может кнопку не нажали?
• Может кнопки нет?
• Может товара нет?
• При каких условиях не добавляется?
• Любой товар не добавляется?
• При каких действиях он не добавляется?
• А если товар не добавляется в определенных условиях и другой товар не добавляется при других условиях. То другая заявка будет также называется? Если нет, то почему бы и эту более точно не написать?

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

Хороший пример - Товар из категории электрика при нажатии на "Купить" не добавляется в корзину.

Таким образом мы при чтении заголовка сразу сузили круг проблемы. При чтении разработчик сразу сможет анализировать следующее:

• Проблема связана только с разделом электрика, а там как раз было недавно исправление, возможно оно поломало логику
• Фикс был небольшой, значит проблема не глобальная, просто в коде немного нужно подправить
• Кнопка существует, значит не верно работает метод, который дергается при её нажатии
• Думаю проблема не сложная, значит её можно назначить на любого разработчика (не обязательно назначать на знающего)

Это всё просто пример, как видите даже добавив несколько слов в ваш заголовок, он сразу может внести много ясности для читающих.

Как уже говорил, это просто структура Заголовка, если не получается ответить на все вопросы «Что? Где? Когда?», то не нужно высасывать из пальца, ответьте только на те, которые считаете нужными. Вот ещё несколько примеров заголовков.

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

1. “Ошибка авторизации при входе в личный кабинет”
2. “Некорректное отображение изображений на главной странице”
3. “Сбой в работе калькулятора в разделе Подсчёт сложного процента”

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

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

1. “Проблемы с кнопкой загрузить”
2. “Не работает формирование отчёта”
3. “Нет описания товара”

Такие заголовки слишком общие и не дают представления о сути проблемы. Они могут вызвать путаницу и затруднить понимание отчета. А самое главное уёдет много времени на исправление ошибки.

Вот ещё несколько советов, как нужно составлять заголовки:

1. Используйте конкретные формулировки. Избегайте общих фраз, таких как “проблемы”, “неполадки” и т.д. Вместо этого укажите конкретную функцию или действие, которое вызывает проблему.
2. Укажите тип проблемы. Если проблема связана с определенной функцией или компонентом системы, укажите это в заголовке.
3. Избегайте двусмысленности. Формулируйте заголовок таким образом, чтобы он не допускал различных толкований.
4. Сделайте заголовок кратким. Чем короче заголовок, тем легче его запомнить и найти в списке отчетов.
5. Проверьте заголовок на точность. Убедитесь, что заголовок точно отражает суть проблемы.
6. Не используйте с излишком обороты речи. Причастные обороты нужная вещь, но не тогда, когда они усложняют понимание.

Описание отчёта о дефекте

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

Основные элементы подробного описания:

1. Контекст проблемы: Описание ситуации, в которой возникает дефект. Это может включать в себя описание действий пользователя, которые приводят к проблеме, или условий среды, в которых она проявляется.
2. Условия возникновения: Указание на конкретные действия или условия, при которых возникает дефект. Это помогает воспроизвести проблему и облегчает её диагностику.
3. Влияние на функциональность: Описание того, как дефект влияет на работу системы. Это может включать в себя потерю данных, неправильное отображение информации или невозможность выполнения определённых функций
4. Ссылки на требования: Если дефект связан с нарушением требований к системе, следует указать соответствующие пункты требований. Это помогает определить, соответствует ли система заявленным стандартам.
5. Дополнительная информация: Любые дополнительные сведения, которые могут быть полезны для понимания и исправления дефекта. Это может включать в себя скриншоты, логи сервера или другую техническую информацию.

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

Шаги воспроизведения

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

Основные принципы составления шагов для воспроизведения:

1. Точность и полнота. Шаги должны быть описаны максимально точно и полно, чтобы любой специалист мог их повторить и получить тот же результат.
2. Последовательность. Шаги должны быть представлены в логической последовательности, чтобы избежать путаницы и ошибок при воспроизведении.
3. Простота. Шаги должны быть простыми и понятными, чтобы минимизировать вероятность ошибок при их выполнении.
4. Избегание лишних деталей. Следует избегать включения в шаги деталей, которые не влияют на воспроизведение проблемы.
5. Использование технических терминов. Если необходимо использовать технические термины, следует дать им определение или пояснение.

Важно помнить о том, что некоторые шаги могут воспроизводиться только при определённых условиях, для этого существует дополнительная колонка с описанием

В следующей статье мы продолжим разбирать атрибуты отчёта о дефекте!

Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний!Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!