Практика: пишем баг-репорт по реальному дефекту в учебном приложении

Зачем это нужно?

Представьте: вы нашли ошибку в программе. Кнопка не работает, текст отображается неправильно, или приложение вдруг закрывается само по себе. Вы радостно сообщаете разработчику: «Эй, там что-то сломалось!» — и что происходит дальше? Разработчик смотрит на вас с недоумением и спрашивает: «Где именно? Что ты делал? Как мне это увидеть?»

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

Хороший баг-репорт — это как подробная инструкция для детектива. Разработчик должен уметь взять ваш репорт, повторить все ваши шаги и увидеть ту же проблему своими глазами. Только тогда он сможет её исправить.

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

Теория: из чего состоит баг-репорт

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

Поле 1. Заголовок (Summary / Title)

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

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

Плохой заголовок:

Не работает

Хороший заголовок:

При нажатии кнопки «Зарегистрироваться» с пустым полем «Email» приложение закрывается без сообщения об ошибке

Разница очевидна: хороший заголовок сразу говорит что, где и при каком условии происходит.

Формула хорошего заголовка:

[Что происходит] + [где] + [при каком условии]

Поле 2. Идентификатор (ID)

Что это: уникальный номер баг-репорта. Нужен, чтобы на него можно было ссылаться в переписке.

Пример: BUG-001, BUG-042

В большинстве команд этот номер присваивается автоматически системой управления задачами (например, Jira или Redmine). На первых порах вы можете назначать номера вручную.

Поле 3. Окружение (Environment)

Что это: описание «среды», в которой вы нашли баг. Один и тот же баг может проявляться только в одном браузере или только на определённой операционной системе.

Что сюда включают:

• Операционная система (например, Windows 11, macOS Ventura, Android 13)
• Браузер и его версия (например, Google Chrome 124, Firefox 115)
• Устройство (компьютер, телефон, планшет)
• Версия приложения (например, версия 2.3.1)

Аналогия: если вы жалуетесь механику, что машина плохо заводится, он обязательно спросит: какая погода, какой бензин, сколько пробег. Это и есть «окружение».

Поле 4. Шаги для воспроизведения (Steps to Reproduce)

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

Это самое важное поле в баг-репорте. Если разработчик не может воспроизвести баг — он не может его исправить.

Правила написания шагов:

1. Каждый шаг — одно конкретное действие
2. Шаги нумеруются по порядку
3. Используйте точные названия кнопок и полей (именно так, как написано в интерфейсе)
4. Не пропускайте «очевидные» шаги — то, что очевидно вам, может быть неочевидно другому человеку

Плохой пример:

Зашёл на сайт, попробовал зарегистрироваться, оно сломалось.

Хороший пример:

1. Открыть браузер Google Chrome.
2. Перейти по адресу: http://учебное-приложение.ru/register
3. Оставить поле «Email» пустым.
4. Заполнить поле «Пароль» значением: Test1234
5. Нажать кнопку «Зарегистрироваться».

Поле 5. Ожидаемый результат (Expected Result)

Что это: что должно было произойти, если бы приложение работало правильно.

Этот пункт часто берётся из технического задания (спецификации) или из здравого смысла.

Пример:

Должно появиться сообщение об ошибке: «Введите адрес электронной почты».

Поле 6. Фактический результат (Actual Result)

Что это: что на самом деле произошло — то, что вы увидели своими глазами.

Пример:

Приложение закрылось без каких-либо сообщений. Страница регистрации исчезла.

Важно: не интерпретируйте и не объясняйте, почему это происходит — просто опишите факт. Вы тестировщик, а не разработчик.

Поле 7. Серьёзность (Severity)

Что это: насколько сильно этот баг влияет на работу программы. Это техническая оценка тестировщика.

Аналогия: серьёзность — как степень тяжести в медицине. Сломанная нога и синяк — это разные случаи.

Поле 8. Приоритет (Priority)

Что это: насколько срочно нужно исправить этот баг. Это управленческое решение, которое часто принимает менеджер или тимлид.

Серьёзность и приоритет — разные вещи. Косметическая ошибка на главной странице может иметь высокий приоритет (потому что клиенты видят её первой), но низкую серьёзность (потому что функционал не нарушен).

Поле 9. Вложения (Attachments)

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

Правила:

• Всегда прикладывайте скриншот или видео, если это возможно
• Подписывайте важные места на скриншоте (стрелка, выделение)
• Видео особенно полезно для багов, которые сложно описать словами

Поле 10. Воспроизводимость (Reproducibility)

Что это: как часто баг воспроизводится при повторении шагов.

Баги с воспроизводимостью «всегда» исправляются проще всего — разработчик может запустить программу и сразу увидеть проблему.

Структура баг-репорта: шаблон

Теперь соберём всё вместе. Вот универсальный шаблон:

ID:              [номер]
Заголовок:       [краткое описание проблемы]
Окружение:       [ОС, браузер, версия приложения]
Воспроизводимость: [всегда / иногда / однажды]
Серьёзность:     [Blocker / Critical / Major / Minor / Trivial]
Приоритет:       [Высокий / Средний / Низкий]

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

Ожидаемый результат:
...

Фактический результат:
...

Вложения:
[скриншоты, видео]

Пример: пишем настоящий баг-репорт

Сценарий

Мы тестируем учебное веб-приложение — простой интернет-магазин под названием «Покупай!». Нам нужно проверить страницу регистрации нового пользователя.

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

Давайте напишем баг-репорт.

ID:              BUG-007
Заголовок:       Система принимает пароль из одних цифр при регистрации, 
                 хотя требования запрещают пароли без букв

Окружение:
  - Операционная система: Windows 11 (64-bit)
  - Браузер: Google Chrome версия 124.0.6367.82
  - Версия приложения: «Покупай!» v1.2.0
  - URL: http://pokupay-test.ru/register

Воспроизводимость: Всегда

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

---

Шаги для воспроизведения:
1. Открыть браузер Google Chrome.
2. Перейти по адресу: http://pokupay-test.ru/register
3. В поле «Имя» ввести: Иван
4. В поле «Email» ввести: [email protected]
5. В поле «Пароль» ввести: 123456  ← только цифры, букв нет
6. В поле «Подтвердите пароль» ввести: 123456
7. Нажать кнопку «Создать аккаунт».

---

Ожидаемый результат:
Система должна отклонить форму и показать сообщение об ошибке под 
полем «Пароль»: «Пароль должен содержать хотя бы одну букву».
Регистрация не должна завершиться успехом.

---

Фактический результат:
Система не показывает никакого сообщения об ошибке. 
Регистрация завершается успешно. Появляется страница 
с текстом: «Добро пожаловать, Иван! Ваш аккаунт создан.»
Пользователь с паролем из одних цифр успешно зарегистрирован в системе.

---

Вложения:
- screenshot_bug007_step7.png  ← скриншот страницы приветствия 
                                  после успешной регистрации
- screenshot_bug007_requirements.png ← скриншот требований к паролю
                                       из документации

Разберём этот пример

Обратите внимание на несколько важных деталей:

1. Заголовок полный и понятный.
Не «Пароль не работает», а точное описание того, что система делает неправильно и при каком условии.

2. Шаги настолько подробные, что их может повторить любой человек.
Мы даже написали конкретное значение пароля (123456), чтобы разработчик использовал именно его.

3. Ожидаемый результат взят из требований.
Мы не придумали его сами — мы сослались на документацию. Это важно: ваша оценка «должно быть вот так» должна иметь основание.

4. Фактический результат описывает факты, не эмоции.
Мы не написали «система ведёт себя ужасно» или «это явная дыра в безопасности». Мы просто описали, что увидели. Оценку дают другие.

5. Серьёзность — Major, а не Critical.
Почему? Потому что слабый пароль — это проблема, но система всё же работает. Если бы баг полностью ломал функцию регистрации для всех пользователей, это был бы Critical.

Типичные ошибки начинающих тестировщиков

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

❌ Ошибка 1: Расплывчатый заголовок

Плохо: «Кнопка не работает»
Хорошо: «Кнопка "Добавить в корзину" на странице товара не реагирует на нажатие в браузере Safari»

❌ Ошибка 2: Пропущенные шаги

Тестировщик написал:

1. Открыть сайт.
2. Нажать "Купить".

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

Правило: проверьте свои шаги, представив, что читаете их первый раз в жизни.

❌ Ошибка 3: Смешение ожидаемого и фактического результата

Плохо:

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

Это два разных поля! Разделите их:

Ожидаемый результат: появляется сообщение «Заполните это поле».
Фактический результат: страница перезагружается, поле «Email» очищается, сообщение об ошибке не появляется.

❌ Ошибка 4: Отсутствие скриншота

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

На Windows скриншот делается клавишей Win + Shift + S (выделить область) или Print Screen (весь экран).
На Mac — Cmd + Shift + 4.

❌ Ошибка 5: Неверная серьёзность

Начинающие тестировщики часто ставят всему «Critical», потому что им кажется, что так на баг обратят больше внимания. Это контрпродуктивно: разработчики перестают доверять оценкам тестировщика.

Пользуйтесь таблицей серьёзности, которую мы разобрали выше.

Практика

Теперь ваша очередь. Ниже описаны четыре ситуации с дефектами в учебном приложении «Покупай!». Для каждой ситуации напишите полный баг-репорт по шаблону из этого урока.

Упражнение 1. Исчезающая корзина

Ситуация:
Вы зашли на сайт http://pokupay-test.ru, выбрали товар «Кружка синяя» и добавили его в корзину. Счётчик рядом с иконкой корзины показал цифру 1. Затем вы перешли на страницу «Каталог» и вернулись обратно. Счётчик корзины снова показывает 0, а товар из корзины исчез.

Требование из документации: «Содержимое корзины должно сохраняться при навигации между страницами сайта».

Ваша задача: напишите полный баг-репорт. Придумайте подходящую серьёзность и объясните свой выбор.

Упражнение 2. Неправильная цена

Ситуация:
На странице каталога товар «Ноутбук Pro» отображается с ценой 45 000 ₽. Вы нажимаете на него, открывается страница самого товара. Там та же цена написана как 54 000 ₽. Вы добавляете товар в корзину — в корзине отображается цена 54 000 ₽.

Требование: «Цена товара должна быть одинаковой на странице каталога и на странице самого товара».

Ваша задача: напишите баг-репорт. Какое поле «Ожидаемый результат» здесь правильное?

Упражнение 3. Кнопка без реакции

Ситуация:
Вы находитесь на странице входа http://pokupay-test.ru/login. Вводите электронную почту [email protected] и пароль Password1. Нажимаете кнопку «Войти». Ничего не происходит — страница не меняется, сообщений нет, загрузки нет. Вы пробуете снова — результат тот же. Вы проверяете в другом браузере (Firefox) — там вход работает нормально.

Требование: «При вводе верных данных пользователь должен переходить на главную страницу своего аккаунта».

Ваша задача: напишите баг-репорт. Обратите особое внимание на поле «Окружение» — здесь оно очень важно.

Упражнение 4. Самостоятельный поиск дефекта

Ваша задача:
Откройте любое реальное приложение или сайт, которым пользуетесь каждый день (например, интернет-магазин, приложение погоды, социальная сеть). Проведите 10–15 минут, исследуя его как тестировщик. Попробуйте найти любую проблему: неправильный текст, неудобное поведение, что-то, что работает не так, как вы ожидаете.

Напишите баг-репорт по найденной проблеме. Если очевидных багов нет — опишите поведение, которое кажется вам нелогичным или неудобным (это тоже ценная информация для команды).

💡 Подсказка для новичков: начните с формы регистрации или входа — там часто можно найти интересные случаи. Попробуйте оставить поля пустыми, ввести очень длинный текст, использовать специальные символы (например, <>@#$).

Краткие итоги урока

• Баг-репорт — это точное и подробное описание найденной ошибки, которое позволяет разработчику воспроизвести и исправить проблему.
• Хороший баг-репорт содержит: заголовок, окружение, шаги для воспроизведения, ожидаемый результат, фактический результат, серьёзность, приоритет и вложения.
• Шаги для воспроизведения — самое важное поле: они должны быть настолько подробными, что их может повторить любой человек.
• Ожидаемый результат берётся из требований или здравого смысла; фактический результат — это только то, что вы видите на экране, без интерпретаций.
• Серьёзность (Severity) — это техническая оценка ущерба от бага; приоритет (Priority) — управленческое решение о срочности исправления. Это разные понятия.
• Всегда прикладывайте скриншоты или видео — они экономят время всей команды.
• Расплывчатые заголовки, пропущенные шаги и смешение ожидаемого с фактическим результатом — три самые частые ошибки начинающих тестировщиков.