Баг-репорт, который чинят с первого раза

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

Минимальный набор

• Заголовок по формуле «где — что — при каком условии». Не «не работает оплата», а «Корзина: кнопка оплаты неактивна после смены адреса доставки».
• Окружение. Версия и сборка приложения, ОС, модель устройства, стенд.
• Шаги — пронумерованные, начиная с понятного исходного состояния.
• Ожидаемый и фактический результат — отдельными строками.
• Доказательства. Видео для UI, логи и запрос/ответ для всего, что связано с сетью.

Чего не хватает чаще всего

Частоты воспроизведения («3 из 10 попыток» — тоже информация) и того, что уже проверено: на другом устройстве, на прошлой сборке, на другом аккаунте. Пара строк об этом экономит разработчику полчаса.

Воспроизводится: 3/10, только Android 14
Не воспроизводится: iOS 18, сборка 5.12.0
Проверено: другой аккаунт — то же самое

И последнее: приоритет — это не громкость. Если всё помечено как критичное, критичного нет. Честная оценка влияния на пользователя помогает команде больше, чем красная метка.