Вы нашли баг, написали отчёт, отправили разработчику… а в ответ получили либо гробовую тишину, либо раздражённое «Так не бывает», либо статус «Отклонено».
Что пошло не так?
Дело не только в сложности бага, но и в том, как он описан. Если ваш баг-репорт вызывает головную боль у разработчиков, его либо игнорируют, либо закрывают без исправления. Давайте разберёмся, какие ошибки в отчётах бесят больше всего.
1. «Не работает»
🔴 Заголовок бага: «Кнопка сломалась»
✅ Как нужно:
В корзине происходит зависание страницы при нажатии кнопки "Отправить"
Предусловие: Ошибка воспроизводится в браузере Chrome 122.0, при нажатии в консоли появляется ошибка 500
Почему это важно? Разработчик не должен гадать, что именно сломалось, где и в каких условиях. Чем точнее описание — тем быстрее исправят проблему.
2. Нет шагов для воспроизведения
🔴 Описание бага: «При попытке оформить заказ сайт зависает»
✅ Как нужно:
«1. Открыть главную страницу
2. Нажать на товар [название]
3. Добавить товар в корзину
4. Перейти в корзину
5. Нажать "Оформить заказ"
6. Выбрать доставку
7. Нажать "Оплатить"
Результат: страница зависает, консоль ошибок не показывает»
Если у разработчика нет чёткого алгоритма действий, он потратит время на догадки. А может, вообще не сможет воспроизвести баг и просто закроет его.
3. Нет информации об окружении
🔴 Описание бага, результат: «Форма авторизации не работает»
✅ Как нужно: «Форма авторизации не позволяет войти в систему, ошибка 401. Воспроизводится на iOS 17.2 в Safari, в других браузерах не повторяется»
Браузер, версия ОС, тестовые данные, логи — это не «дополнительная информация», а критически важные детали, без которых баг может так и остаться загадкой.
4. Лишняя эмоциональность
🔴 Описание бага: «Опять всё сломалось, исправьте уже наконец!»
✅ Как нужно: «После обновления версия 2.3.5 страница "Мои заказы" не загружается, ошибка 403. До обновления всё работало»
Разработчики такие же люди, и если баг-репорт написан с раздражением, он вызывает не желание разобраться, а желание отправить его в архив.
5. Неправильный приоритет
🔴 Описание бага: «Текст в кнопке на 1 пиксель смещён! Срочно исправить!!! (Priority: Blocker)»
✅ Как нужно: «Текст на кнопке "Купить" немного смещён вправо на 1 пиксель. Воспроизводится в Firefox. (Priority: Minor)»
Не все баги критичны. Если каждый мелкий UI-баг помечать как Blocker, разработчики перестанут воспринимать приоритет всерьёз.
Хороший баг-репорт — это половина пути к его исправлению. Если описание понятное, чёткое и без эмоций, разработчик быстрее найдёт проблему и решит её. А если репорт написан в духе «что-то не так, но я не скажу что» — скорее всего, он просто останется без внимания.