Когда тестировщик находит ошибку в программе или на сайте, он оформляет баг-репорт — документ, который помогает разработчикам понять и исправить проблему. Но чтобы баг был исправлен быстро и правильно, важно корректно его классифицировать. Давайте разберёмся, какие поля должны быть в баг-репорте и как правильно определять серьёзность и приоритет ошибки.
Обязательные поля баг-репорта
- Серьёзность (Severity) — насколько баг критичен для работы продукта.
- Приоритет (Priority) — как срочно нужно исправить ошибку.
- Окружение — условия, в которых баг проявился (браузер, ОС, устройство).
- Версия приложения — номер сборки, в которой обнаружен баг.
Некоторые компании объединяют «Окружение» и «Версию приложения», но лучше указывать их отдельно — так информация будет точнее.
Необязательные, но полезные поля
- Описание — дополнительные детали, не вошедшие в заголовок.
- Предусловие — что нужно сделать перед воспроизведением бага (например, зарегистрироваться).
- Постусловие — действия после тестирования (например, выйти из аккаунта).
- Дополнительные материалы — скриншоты, видео, логи.
Классификация багов по серьёзности
Серьёзность показывает, насколько баг мешает работе пользователя. В разных компаниях градация может отличаться, но чаще всего используют следующие уровни:
- Блокирующий (Blocker) — продукт полностью неработоспособен.
Пример: в интернет-магазине не работает корзина — пользователи не могут ничего купить. - Критический (Critical) — часть функций не работает, но есть обходные пути.
Пример: кнопка «Купить» не работает для авторизованных пользователей, но гости сайта могут совершать покупки. - Высокий (Major) — продукт работает, но с заметными ошибками.
Пример: при добавлении товара в корзину появляется ошибка, но товар всё равно добавляется. - Низкий (Minor) — неудобства, не мешающие основному функционалу.
Пример: не работает сортировка товаров по цене. - Незначительный (Trivial) — косметические дефекты, не влияющие на работу.
Пример: опечатка в названии раздела («Книга» вместо «Книги»).
Приоритет исправления
Приоритет определяет, насколько срочно нужно чинить баг:
- Высокий — ошибка блокирует работу, исправлять нужно немедленно.
- Средний — проблема не критична, но требует исправления в ближайшее время.
- Низкий — можно починить в последнюю очередь.
Почему важно указывать окружение и версию приложения?
Баг может проявляться только в определённых условиях:
- в конкретном браузере (например, только в Chrome 89),
- на определённой ОС (Windows 10, но не на macOS),
- на мобильном устройстве (Xiaomi Redmi Note 4).
Без этой информации разработчик может не воспроизвести ошибку и не сможет её исправить.
Правильная классификация багов ускоряет их исправление. Чем точнее тестировщик заполнит баг-репорт, тем быстрее разработчики поймут проблему и устранят её. Главное — не забывать про обязательные поля и чётко определять серьёзность и приоритет ошибки.
Баг или фича-реквест: как отличить и что делать
Во время тестирования приложения или сайта можно обнаружить разные несоответствия: одни — явные ошибки, другие — возможности для улучшения, а третьи и вовсе оказываются неожиданными «сюрпризами». Как понять, что перед вами — баг, фича-реквест или недокументированная возможность? Давайте разберёмся.
Когда перед нами баг?
Баг — это ошибка, из-за которой система ведёт себя не так, как описано в требованиях. Например:
- После регистрации пользователь не получает подтверждающее письмо, хотя в ТЗ указано, что оно должно приходить.
- Кнопка «Отправить» не работает при определённых условиях.
Как действовать:
- Сверяемся с документацией.
- Если поведение системы явно противоречит требованиям — оформляем баг-репорт.
- Указываем критичность и приоритет.
Когда это фича-реквест?
Фича-реквест — это предложение по улучшению функционала, которого нет в текущих требованиях, но оно сделает продукт удобнее. Например:
- В поле ввода телефона можно добавить маску (+7 (XXX) XXX-XX-XX), чтобы пользователи вводили номер правильно.
- Добавить подсказки при заполнении формы.
Как действовать:
- Обсуждаем с командой (продукт-менеджером, аналитиком).
- Если идея действительно улучшит UX — оформляем задачу как feature request.
- Ждём оценки и планирования доработки.
А если это недокументированная возможность?
Иногда во время тестирования обнаруживается функционал, который не описан в требованиях. Например:
- Пользователь может отменить заказ через скрытую кнопку в личном кабинете.
- Система автоматически применяет скидку при определённых условиях, хотя в ТЗ этого нет.
Как действовать:
- Проверяем, не было ли это сделано намеренно (уточняем у аналитика или разработчика).
- Если это ошибка — оформляем баг.
- Если это полезная, но незадокументированная фича — обсуждаем, нужно ли её оставить или доработать.
Почему важно различать баги и фича-реквесты?
- Баг требует срочного исправления, так как это отклонение от утверждённого функционала.
- Фича-реквест — это улучшение, которое может подождать следующего спринта или релиза.
- Недокументированные возможности могут быть как опасными уязвимостями, так и полезными «пасхалками» — их нужно проверять в первую очередь.
Вывод
Прежде чем заводить баг-репорт, задайте себе вопросы:
✅ Это явное отклонение от требований? → Баг.
✅ Это улучшение, которого нет в ТЗ? → Фича-реквест.
✅ Это что-то странное и неочевидное? → Проверить у команды.
Главное — не спешить и уточнять спорные моменты. А как вы отличаете баги от фич в своих проектах? Делитесь в комментариях! 🚀