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

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

В статье разберёмся, из каких элементов состоит хороший отчёт об ошибке (баг-репорт), чем серьёзность отличается от приоритета и какие ошибки чаще всего допускают начинающие тестировщики.

Баг-репорт — это документированное описание обнаруженной проблемы в программном продукте. Обычно такие отчёты создают в Jira, YouTrack или другой системе управления задачами.

Главная цель баг-репорта — передать команде всю информацию, необходимую для анализа и исправления проблемы. Из баг-репорта должно быть понятно:

Качественно оформленный баг-репорт сокращает количество дополнительных вопросов и помогает быстрее проверить исправление.

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

Единой классификации для всех IT-проектов не существует. Команда выбирает категории с учётом архитектуры, платформы и особенностей продукта. Тем не менее можно выделить несколько распространённых типов дефектов.

Система выполняет действие неправильно или не выполняет его вообще.

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

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

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

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

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

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

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

Проверьте:

Набор полей зависит от процессов конкретной команды, но основные элементы обычно совпадают.

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

Удобная формула:

Пример:

Неудачные варианты:

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

В этом разделе указывают условия, при которых был обнаружен дефект:

Предусловия показывают, в каком состоянии должна находиться система перед выполнением шагов.

Например:

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

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

Каждый шаг лучше описывать отдельным пунктом:

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

Здесь фиксируют то, что произошло на самом деле.

После перехода по ссылке отображается пустая страница с сообщением «500 Internal Server Error». Форма создания нового пароля не открывается.

Фактический результат должен описывать наблюдаемое поведение, а не предположение тестировщика о причине ошибки.

В этом поле указывают корректное поведение системы на основании требований, дизайна или согласованной логики продукта.

Например:

Открывается форма, в которой пользователь может указать и подтвердить новый пароль.

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

Баг-репорт также включает серьёзность дефекта — Blocker, Critical, Major, Minor или Trivial — и приоритет исправления: P1 (Critical), P2 (High), P3 (Medium) или P4 (Low). Подробнее об этих параметрах расскажем ниже.

[Web][Восстановление пароля] После перехода по действующей ссылке в Firefox открывается ошибка 500

Staging, build 4.18.2
macOS 15.6
Firefox 148.0

Открывается страница с сообщением «500 Internal Server Error». Форма изменения пароля не отображается. В консоли зафиксирован ответ сервера со статусом 500.

Открывается форма для ввода и подтверждения нового пароля.

Серьёзность, или severity, показывает, насколько сильно баг нарушает работу продукта.

В командах могут использоваться следующие уровни:

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

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

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

Например, команда может использовать следующую классификацию:

P1 — Critical требует немедленного исправления,

P2 — High — исправления в ближайшее время,

P3 — Medium обозначает проблему средней срочности

P4 — Low — незначительный дефект, исправление которого может подождать.

Названия и количество уровней могут различаться в зависимости от проекта.

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

Статус баг-репорта указывается в системе управления задачами, например в YouTrack. Он выбирается из выпадающего списка и показывает, на каком этапе обработки находится дефект.

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

Фраза «Кнопка не работает» не объясняет, о какой кнопке идёт речь, где она находится и что происходит после нажатия.

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

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

Не стоит писать, что страница выглядит «странно» или работает «ужасно». Лучше зафиксировать конкретное наблюдение: элемент перекрывает текст, загрузка занимает 18 секунд, кнопка не реагирует на нажатие.

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

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