Детектив-тестировщик ищет ошибки и составляет баг-репорт

Баг-репорт: описание, правила, примеры

Что такое баг-репорт для тестировщика: это главный инструмент а артефактах тестирования ПО.

Представьте, что вы детектив. Вы нашли улику — зацепку, которая поможет раскрыть дело. Но что толку, если вы просто положите её в карман? Нужно составить подробный протокол: описать, где нашли, что из себя представляет, почему это важно. Так и в IT-мире: тестировщик — это детектив, который ищет «улики» — ошибки в программе. А его главный документ — это баг-репорт.

Баг-репорт (Bug Report) — это технический документ, который описывает ситуацию или последовательность действий, которые привели объект тестирования к неправильной работе, с указанием причин и ожидаемого результата. Его цель — чётко и понятно объяснить разработчику, что пошло не так, где это случилось и когда, при каких условиях.

  • Баг (Bug) [баг] — ошибка, дефект в программе. В буквальном переводе с английского — «жучок». История гласит, что первый «баг» был настоящим мотыльком, застрявшим в реле компьютера в 1947 году!

  • Репорт (Report) [ри-порт] — отчёт, доклад.

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

Детектив-тестировщик ищет ошибки и составляет баг-репорт


Зачем он нужен? Простые цели сложной работы

Качественный баг-репорт решает сразу несколько задач:

  • Сообщить о проблеме: Донести до команды факт существования дефекта.

  • Воспроизвести ошибку: Дать разработчику чёткую инструкцию, чтобы он сам увидел проблему.

  • Зафиксировать историю: Создать запись для анализа статистики и повторяющихся проблем.

  • Ускорить исправление: Чем яснее описан баг, тем быстрее программист его поймёт и исправит.


Из чего состоит идеальный баг-репорт? (Структура)

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

1. Заголовок

Заголовок (Title/Summary) [тайтл / са-мэ-ри] – Краткое описание.

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

Простой короткий и понятный заголовок должен отвечать вопросам:

  • Что не работает
  • Где, в каком месте, не работает
  • Когда это произошло или происходит

Плохо: «Не работает кнопка»
Хорошо: «Кнопка «Отправить»(что?) неактивна после заполнения(когда происходит?) всех обязательных полей в форме (где?) «Обратная связь»»

2. Краткое описание

Описание (Description) [дис-крип-шн] – Детали проблемы.

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

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

Шаги для воспроизведения (Steps to Reproduce) [стэпс ту ри-про-дьюс] – Инструкция для разработчика.

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

  • Шаг 1: Перейдите на сайт example.com.

  • Шаг 2: Нажмите на кнопку «Войти».

  • Шаг 3: Введите логин «test_user».

  • Шаг 4: Введите пароль «12345».

  • Шаг 5: Нажмите кнопку «Отправить».

4. Фактический и Ожидаемый результат

Фактический и Ожидаемый результат (Actual and Expected Result) [ак-чу-эл энд ик-спек-тид ри-золт] – Что случилось/Что должно было случиться

Чёткое разделение этих понятий — залог понимания.

Фактический результат (Что происходит на самом деле)Ожидаемый результат (Что должно было произойти по моему мнению)
Сообщение «Неверный пароль», пользователь остаётся на странице входа.Пользователь входит в систему и перенаправляется в личный кабинет.

5. Серьёзность

Серьёзность (Severity) [се-вэ-ри-ти] – Влияние на продукт. Показывает, насколько баг критичен для работы приложения в целом.

  • Блокирующий (Blocker): Приложение не запускается или ключевая функция полностью не работает.

  • Критический (Critical): Ключевая функция бизнес-логики работает неверно, проблемы вызывающие временные сбои сервера или серьезные сбои в безопасности, без обходных путей.

  • Значительный (Major): Ключевая часть бизнес-логики работает некорректно, ошибка не критична или есть возможность работать с функцией используя другие точки входа .

  • Незначительный (Minor): Ошибка которая не нарушат функции бизнес-логики. Небольшая опечатка, неудобный, но рабочий элемент интерфейса.

6. Приоритет

Приоритет (Priority) [прай-о-ри-ти] – Очерёдность исправления. Показывает, насколько срочно нужно исправлять баг.

  • Высокий (High): Нужно исправить в ближайшем обновлении.

  • Средний (Medium): Нужно исправить, но не срочно.

  • Низкий (Low): Можно исправить, когда будет время.

Важно: Серьёзность и приоритет — не одно и то же! Опечатка в логотипе (Severity Minor) может иметь высокий приоритет (Priority High) для исправления, так как бьёт по имиджу.

7. Окружение

Окружение (Environment) [ин-вай-эрн-мэнт] – Где нашли баг? Указывают точные параметры системы, на которой тестировали. Ошибка может проявляться только в определённых условиях.

  • Операционная система: Windows 11 / macOS Ventura

  • Браузер и его версия: Google Chrome 118.0

  • Версия приложения: v.2.1.5

8. Приложения

Приложения (Attachments) [эт-тэч-мэнтс] – Доказательства. Картинка стоит сотни слов. Обязательно прикрепляют:

  • Скриншоты (Screenshot) [скрин-шот]: Визуальное подтверждение проблемы.

  • Видеозапись (Screen Recording) [скрин ри-кор-динг]: Если баг сложно воспроизвести статично.

  • Лог-файлы (Logs) [логз]: Текстовые файлы с технической информацией о работе программы.


Стиль текста и время

При составлении шагов воспроизведения (Steps to Reproduce) в баг-репорте пишут в повелительном наклонении (imperative mood) и в настоящем времени (Present Simple).

 Почему так:

  • Повелительное наклонение — делает инструкцию чёткой и пошаговой.
    → Это стиль инструкций, как в чек-листах или мануалах.

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

✅ Пример правильного оформления:

ОписанияКомментарий
1Откройте страницу входаПовелительное наклонение («откройте»)
2Введите валидные логин и парольНастоящее время
3Нажмите кнопку ВойтиКонкретное действие
4Ошибка: «Кнопка неактивна».Завершает сценарий

❌ Как писать не нужно:

  • «Я открыл страницу входа» — прошедшее время, повествование.

  • «Открываю страницу входа» — настоящее длительное, не подходит для инструкций.

  • «Пользователь должен открыть страницу входа» — будущее/общее описание, а не шаг.


Пример баг-репорта в действии

Заголовок: Курсор мыши исчезает при наведении на поле поиска в главном меню.

Описание: На всех страницах сайта example.com курсор мыши исчезает в поле поиска на главном меню.

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

  1. Откройте главную страницу сайта example.com.

  2. Наведите курсор мыши на поле поиска в верхней части страницы в главном меню.

Фактический результат: Курсор мыши полностью исчезает с экрана в момент наведения его в поле поиска.

Ожидаемый результат: Курсор, в момент наведения его в поле поиска, меняет вид на текстовый (вертикальную черту), поле подсвечивается.

Серьёзность:  Значительный (Major)
Приоритет: Средний (Medium)

Окружение: Windows 10, Google Chrome 119.0.6045.200, v.1.0.0.

Приложения: [Скриншот области поиска с отсутствующим курсором, видео с демонстрацией исчезновения].


Подробные примеры хороших и плохих баг-репортот

ТипПримерКомментарий
1Название: Кнопка «Сохранить» не работает на странице профиля
Описание: При клике на кнопку «Сохранить» изменения профиля не сохраняются.
Шаги: 1. Откройте профиль. 2. Измените имя. 3. Нажмите «Сохранить».
Ожидаемый результат: Система сохраняет изменения.
Фактический результат: Система не сохраняет изменения.
Окружение: Chrome 118.0, Windows 10.
Чёткие шаги, понятное поведение.
2Название: Поле «Email» принимает некорректные форматы
Описание: Введите в поле Email «test@com» — система принимает недопустимый формат.
Шаги: 1. Откройте форму регистрации. 2. Введите «test@com». 3. Нажмите «Зарегистрироваться».
Ожидаемый результат: Система отклоняет некорректный адрес.
Фактический результат: Система принимает некорректный адрес.
Окружение: Chrome 118.0, Windows 10.
Конкретно описано, легко воспроизвести.
3Название: Выпадающее меню «Категории» обрезается на мобильных устройствах
Описание: На экране обрезается часть пунктов меню.
Шаги: 1. Откройте сайт на iPhone 14. 2. Нажмите на меню «Категории».
Ожидаемый результат: Все пункты меню отображаются.
Фактический результат: Часть пунктов меню не отображается.
Окружение: iPhone 14, iOS 17, Safari.
Хорошо описано поведение на устройстве.
4Название: Ошибка 500 при отправке формы обратной связи
Описание: При отправке формы с любым текстом сервер возвращает ошибку 500.
Шаги: 1. Откройте страницу обратной связи. 2. Введите текст. 3. Нажмите «Отправить».
Ожидаемый результат: Форма отправляется без ошибок.
Фактический результат: Сервер возвращает ошибку 500.
Окружение: Firefox 120.0, Chrome 118.0, Windows 10.
Понятное описание, легко проверить.
5Название: Таймер сессии сбрасывается после обновления страницы
Описание: При обновлении страницы таймер обнуляется.
Шаги: 1. Авторизуйтесь. 2. Запустите таймер. 3. Обновите страницу.
Ожидаемый результат: Таймер продолжает отсчёт.
Фактический результат: Таймер сбрасывается на 30 минут.
Окружение: Chrome 118.0, Windows 10.
Чёткое описание поведения и последствий.
6Название: Страница профиля странная
Описание: Когда захожу на страницу профиля, вижу что-то непонятное.
Нет конкретики и шагов.
7Название: Кнопка «ОК» ведёт себя странно
Описание: Иногда не срабатывает, не понятно почему.
Нет условий воспроизведения.
8Название: Ошибка при регистрации
Описание: Выдаёт ошибку, не знаю какую.
Нет точных данных об ошибке.
9Название: Не сохраняет данные
Описание: Иногда данные не сохраняются, неясно при каких условиях.
Сложно воспроизвести.
10Название: Программа падает
Описание: Падает, когда пользуюсь.
Нет сценария и окружения.

Итог: Ваш баг-репорт — это ваша профессиональная визитка

Написание качественного баг-репорта — это не бюрократия, а высокоценный навык. Это голос тестировщика в команде разработки. Хороший отчёт демонстрирует внимательность, аналитические способности и стремление сделать продукт лучше.  Цель — не просто найти ошибку, а сделать так, чтобы её было легко, быстро исправить и впредь быть готовым к ней.

Почему важна специализированная система?

Раньше баги записывали в тетрадки или Excel, но это было неудобно и мешало командной работе. Современные TRACing Systems (TRACking) [трэкинг] — системы отслеживания ошибок — это целые экосистемы, которые:

  • Хранят всю историю об ошибке в одном месте.

  • Автоматизируют workflows (вёркфлоу) — рабочие процессы: назначение, приоритизацию, статусы.

  • Дают аналитику для менеджеров.

  • Интегрируются с другими инструментами (например, с Slack, GitHub).

Комментарии

Комментариев пока нет. Почему бы ’Вам не начать обсуждение?

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *