Сделаем bugreport чуточку полезней

Привет, меня зовут Игорь, я СТО команды Tproger.ru. Расскажу, как мы оформляем отчёты об ошибках.

Зачем нужны отчёты

Зачем менеджеру составлять какой-то отчёт об ошибке и тратить на него своё время, а не просто написать о проблеме?

Дело в том, что исправление ошибки напрямую зависит от того, кто с ней пришёл, и насколько эффективно он про неё сообщит. Если отчёт описан максимально корректно, то и шансы на исправление ошибки становятся больше, а времени, соответственно, меньше.

Посмотрим на примере: допустим, наш продукт успешно работает, и ничего не предвещало беды, как вдруг вылез баг.

Разработчик, у которого работает сайт без багов

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

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

Но, по разным причинам, не у всех команд есть полноценный таск-менеджер для этих целей. Зачастую это отдельный канал или чат, куда всё сваливают разработке.

Пример того, как зачастую происходит коммуникация между разработчиками и менеджерами при неотлаженных процессах:

Эй, разработчик, у нас не работает кнопка для формирования отчета!

Канал с багамиМенеджер

В таком случае команда разработки выделяет ресурсы на анализ ситуации и действует по алгоритму:

1. Проверяет работу кнопки, пытаясь опытным путём повторить ошибку.
2. Находит ошибку, описывает спецификацию, оценивает сроки.
3. Ошибка берется в работу.

Когда ошибка пойдет в работу, зависит от её сложности, приоритета и того, как она влияет на работу продукта.

Но казалось бы, это такой простой путь, и что вообще может пойти не так, и почему бы просто не исправить ошибку. Проблема в пункте №1: из-за отсутствия достаточного количества информации поиск проблемы может занять неопределённое время, что естественно повлияет на весь срок выполнения.

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

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

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

Рекомендации написания отчёта об ошибке

1. Воспроизведение: прежде чем передать ошибку в разработку, убедиться, что она повторяется, желательно несколько раз. Воспроизвести процесс и описать действия шаг за шагом.
2. Проверка на существование: перед созданием отчёта поищите в бэклоге. Возможно, кто-то уже нашел ошибку, и разработчики уже знают о ней.
3. Краткое описание: минимум слов, только по делу. Одна проблема, один отчёт. По краткому описанию удобно вести навигацию среди большого бэклога.
4. Полное описание: описать ошибку и путь её достижения. Чем подробнее будет описан путь, тем легче будет повторить ошибку, найти и исправить.
5. Окружение: ОС, браузер, устройство, иные технические моменты, которые могли повлиять на баг (VPN, режим Инкогнито, Adblock и прочее).
6. Вместо тысячи слов: приложить к отчёту скриншоты или запись с экрана. Зачастую такая информация содержит больше полезной информации, нежели текстовое описание.
7. Ожидание и результат: описать, как все должно работать, какое поведение и результат были получены, какой ожидаемый результат и путь к нему.
8. Место происшествия: указать источник ошибки. Если это веб-приложение, указать полный url. Если иное, указать окно\вкладку и т.д.
9. Журналы ошибок: любые локальные логи помогут быстрее разобраться в ошибке. Сообщения в консоли браузера, ошибки в системе, любые alert’ы.
10. Приоритет: указать, насколько ошибка влияет на работу продукта. Исходя из приоритета, команда разработки сможет принять решение, как быстро приступить к её исправлению.

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

• Не могу подписаться на тег.
• Нужно срочно починить.

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

• Убедился несколько раз в ошибке, смог повторить.
• В беклоге не нашел ничего похожего, можно создавать.
• Не могу подписаться на тег java.
• Залогинен, открываю любую статью с тегом java, кликаю на тег для подписки, но ничего не происходит. При этом на остальные теги могу подписаться без ошибок.
• ОС linux mint, Google Chrome Версия 112.0.5615.165 (Официальная сборка), (64 бит), Адблок был и включен, и выключен.
• Скриншот или видео. 
• Ожидаю, что после клика смогу подписаться на тег java и получать уведомления о выходе новых постов на сайте с этим тегом.
• Статья с тегом java.
• Failed to load resource: the server responded with a status of 404 ()
• Баг очень важный, его нужно сделать вчера.

Таким образом, потратив не намного больше времени на подготовку отчёта, менеджер принимает непосредственное участие, создав понятную задачу, которую разработчик может сразу взять в работу, не тратя ресурсы на её изучение.

Поделитесь, как вы проводите обработку ошибок в своей команде.