Оформлять репорт так, чтобы не раздражать разработчиков и менеджеров
#почитать #junior
▫️Воспроизведение: прежде чем передать ошибку в разработку, убедиться, что она повторяется, желательно несколько раз. Воспроизвести процесс и описать действия шаг за шагом.
▫️Проверка на существование: перед созданием отчёта поищите в бэклоге. Возможно, кто-то уже нашел ошибку, и разработчики уже знают о ней.
▫️Краткое описание: минимум слов, только по делу. Одна проблема, один отчёт. По краткому описанию удобно вести навигацию среди большого бэклога.
▫️Полное описание: описать ошибку и путь её достижения. Чем подробнее будет описан путь, тем легче будет повторить ошибку, найти и исправить.
▫️Окружение: ОС, браузер, устройство, иные технические моменты, которые могли повлиять на баг (VPN, режим Инкогнито, Adblock и прочее).
▫️Вместо тысячи слов: приложить к отчёту скриншоты или запись с экрана. Зачастую такая информация содержит больше полезной информации, нежели текстовое описание.
▫️Ожидание и результат: описать, как все должно работать, какое поведение и результат были получены, какой ожидаемый результат и путь к нему.
▫️Место происшествия: указать источник ошибки. Если это веб-приложение, указать полный url. Если иное, указать окно\вкладку и т.д.
▫️Журналы ошибок: любые локальные логи помогут быстрее разобраться в ошибке. Сообщения в консоли браузера, ошибки в системе, любые alert'ы.
▫️Приоритет: указать, насколько ошибка влияет на работу продукта. Исходя из приоритета, команда разработки сможет принять решение, как быстро приступить к её исправлению.
Подробнее
#почитать #junior
▫️Воспроизведение: прежде чем передать ошибку в разработку, убедиться, что она повторяется, желательно несколько раз. Воспроизвести процесс и описать действия шаг за шагом.
▫️Проверка на существование: перед созданием отчёта поищите в бэклоге. Возможно, кто-то уже нашел ошибку, и разработчики уже знают о ней.
▫️Краткое описание: минимум слов, только по делу. Одна проблема, один отчёт. По краткому описанию удобно вести навигацию среди большого бэклога.
▫️Полное описание: описать ошибку и путь её достижения. Чем подробнее будет описан путь, тем легче будет повторить ошибку, найти и исправить.
▫️Окружение: ОС, браузер, устройство, иные технические моменты, которые могли повлиять на баг (VPN, режим Инкогнито, Adblock и прочее).
▫️Вместо тысячи слов: приложить к отчёту скриншоты или запись с экрана. Зачастую такая информация содержит больше полезной информации, нежели текстовое описание.
▫️Ожидание и результат: описать, как все должно работать, какое поведение и результат были получены, какой ожидаемый результат и путь к нему.
▫️Место происшествия: указать источник ошибки. Если это веб-приложение, указать полный url. Если иное, указать окно\вкладку и т.д.
▫️Журналы ошибок: любые локальные логи помогут быстрее разобраться в ошибке. Сообщения в консоли браузера, ошибки в системе, любые alert'ы.
▫️Приоритет: указать, насколько ошибка влияет на работу продукта. Исходя из приоритета, команда разработки сможет принять решение, как быстро приступить к её исправлению.
Подробнее