Баг-репорт: как правильно фиксировать ошибки в ПО

Что такое баг и откуда появился этот термин?

Баг (от англ. "bug" — жук) — это отклонение фактического поведения программы от ожидаемого. Простыми словами — когда программа работает не так, как должна.

Интересный факт: термин появился ещё в XIX веке! Телеграфисты называли так технические неисправности, которые было сложно устранить — они надоедали, как назойливые жуки.

А в 1947 году в компьютере Mark II нашли реального мотылька, застрявшего в реле и вызвавшего сбой. Его даже вклеили в журнал с пометкой "Первый обнаруженный баг". С тех пор 9 сентября считается неофициальным Днём тестировщика.

Жизненный цикл бага

Каждый баг проходит определённые этапы:

1. Открыт — ошибка обнаружена и зафиксирована
2. Приоритизация — определяется важность исправления
3. Анализ — уточняются детали и причины
4. В работе — разработчик исправляет ошибку
5. Решён — исправление готово к проверке
6. Тестирование — QA проверяет исправление
7. Закрыт — баг устранён

Баг может возвращаться на предыдущие этапы, если:

• Не хватает информации для исправления
• Ошибка воспроизводится после "исправления"
• Оказалось, что это не баг, а особенность работы (фича)

Виды багов

1. Визуальные (UI)
   Пример: кнопка "Отправить" съехала за границу экрана
   Как проверить: сравнить с макетом дизайнера
2. Функциональные
   Пример: при нажатии "Сохранить" данные не сохраняются
   Как проверить: выполнить действие и проверить результат
3. UX (удобство использования)
   Пример: для ввода номера телефона нужно сделать 10 кликов
   Как проверить: оценить удобство выполнения типовых сценариев
4. Нефункциональные
   Пример: страница загружается 15 секунд
   Как проверить: замерить время отклика системы
5. Логические (в требованиях)
   Пример: система позволяет оформить заказ отсутствующего товара
   Как проверить: сверить поведение системы с бизнес-логикой

Как определять важность багов?

Для оценки используют два параметра:

Серьёзность (Severity) — насколько баг мешает работе:

• S1 Блокирующий: система не работает вообще
• S2 Критический: не работает ключевая функция
• S3 Значительный: есть обходной путь
• S4 Незначительный: влияет только на внешний вид
• S5 Тривиальный: опечатки, мелкие косметические дефекты

Приоритет (Priority) — как быстро нужно исправить:

• P1 Высокий: исправить в первую очередь
• P2 Средний: исправить после критических
• P3 Низкий: исправить, когда будет время

Как правильно оформить баг-репорт?

Хороший баг-репорт должен содержать:

1. Краткое описание
   Плохо: "Что-то не работает"
   Хорошо: "Не сохраняется пароль при регистрации"
2. Шаги воспроизведения

1. Открыть сайт example.com
2. Нажать "Регистрация"
3. Ввести логин "test" и пароль "123"
4. Нажать "Сохранить"

1. Фактический результат
   "Пароль не сохраняется в базе данных"
2. Ожидаемый результат
   "Пароль должен сохраняться в зашифрованном виде"
3. Дополнительная информация
   Окружение: Chrome 122, Windows 11
   Скриншоты/видео
   Логи ошибок

Полезные советы

✔ Проверяйте перед отправкой — убедитесь, что баг воспроизводится
✔ Один баг — один отчёт — не объединяйте несколько проблем
✔ Будьте конкретны — вместо "не работает" пишите что именно
✔ Добавляйте доказательства — скриншоты, логи, видео
✔ Следите за статусами — вовремя отвечайте на уточнения

Популярные системы для учёта багов

• Jira
• Яндекс.Трекер
• YouTrack
• Redmine
• Mantis

Помните: хороший баг-репорт экономит время всей команды и помогает выпускать качественный продукт!