Жучок в коде. И это не про насекомое, а про тот самый «баг», которого все боятся. Но он всегда приходит и это нормально. Важно знать, как писать bug report, как работать с этим документом и исправлять ошибки в коде, опираясь на данные от тестировщика. Разберем, как составлять грамотный bug report.
Что такое bug report и зачем он нужен
Тестировщик исследует код и находит ошибку. Как ему донести до разработчика, что произошла эта ошибка? А как разработчику быстро понять, что именно нужно исправлять и где нужно поискать «жучка»?
Для этого и существует bug report. Это структурированный по определенным правилам отчет, цель которого помочь быстро обнаружить проблему и найти решение.
Как правило, такие отчеты пишут тестировщики, а работают с этой документацией разработчики. Но баг может обнаружить пользователь, менеджер, или другой разработчик. Поэтому, какая бы роль на проекте у вас не была, важно уметь работать с bug report. Составлять его, правильно читать, запрашивать недостающие данные и реагировать — вносить изменения.
Зачем нужен bug report
«Не работает функционал», «Тут что-то поламалось, не открывается». Представьте, если вам, как разработчику, поставили так задачу. Непонятно, что делать? Вот именно. Для этого и нужен bug report. Если точнее, этот документ позволяет:
- зафиксировать проблему, чтобы она была точно решена и не затерялась;
- определить серьезность бага и приоритет решения задачи;
- сэкономить время разработчиков на поиск причины и решения проблемы;
- поддерживать проект в технически рабочем состоянии.
Баги есть и будут всегда. Вопрос только в том, как быстро их получится решить. Для этого нужен bug report и грамотная с ним работа.
Как составить bug report, чтобы быстро решать технические проблемы
Эти рекомендации помогут как тестировщикам, так и разработчикам, проектным менеджерам. В идеале в компании должны быть прописаны требования к составлению bug report. В первую очередь вы должны следовать требованиям собственной компании. Но не всегда эти требования есть, или не в полной мере раскрыты. Эти рекомендации помогут сделать качественный bug report и исправлять баги быстро.
Структура bug report
Правильная структура — залог успешной работы всей команды. Следуйте базовым правилам структуры:
- Четко и строго сформулированная тема. Не просто «не работает кнопка», а конкретно: «При нажатии с телефона на кнопку не происходит никаких действий». В идеале использовать формулу: Что-Где-Когда. Что происходит, где именно, когда (в какой момент).
- Описание bug report. В нескольких предложениях опишите ситуацию. Представьте, что вы пишите человеку, который совершенно не знаком с проектом. Он поймет, о чем именно вы написали? Пример: «На телефоне Xiaomi на странице товара при нажатии на кнопку «Купить» ничего не происходит. Нет оповещений, информации, добавился ли товар в корзину. Я не понимаю, что мне дальше делать на странице и как продолжить покупку».
- Пошаговый путь. Опишите свой путь, чтобы другой человек мог повторить этот баг. Пошагово. Что и в какой последовательности вы нажимали и куда заходили. В идеале разработчик должен повторить путь и попасть на этот же баг.
- Ожидаемый результат. «Жду, что кнопка будет работать» — это не ожидаемый результат для bug report. Опишите, что именно должно происходить после решения бага. В нашем примере так: «После нажатия на кнопку «Купить» всплывает поп-ап окно, в котором написано, что товар добавлен в корзину. Там есть 2 кнопки: перейти к оплате и вернуться к товарам».
- Технические атрибуты. В bug report нужно прописать все технические моменты задачи. Данные про спринт, среду разработки, операционную систему, которая использовалась при обнаружении бага. Технические описания помогут как можно скорее определить баг и решить его.
- Дополнительные данные. Помогут скриншоты, запись экрана, описанные детали или другие данные, которые ускорят процесс. Чтобы собрать их, поставьте себя на место человека, который будет читать bug report. Вы сможете все понять, если вас вырвать из контекста проблемы? Если да, это хороший bug report.
Это «Золотая структура» баг репорта. Но могут быть нюансы. Обращайте внимание на требования, изложенные в вашей компании.
Что важно учесть при работе с bug report
В одном bug report — одна проблема. Нередко обнаруживается сразу несколько багов в одном месте. Но каждый репорт должен быть посвящен строго одной проблеме. Иначе начнется путаница.
Покажите серьезность влияния бага. Не все то «жучки», что мы видим. Некоторые проблемы очень простые и не влияют на функционал. Другие являются критичными.
Избегайте излишней эмоциональности. Не нужно писать, что «все пропало». Голова должна быть холодной. Четко и по делу. Информация должна быть детальной, но лаконичной. Никто не хочет читать километры текста.
Объективность — ваш друг. Писать что-то типа «По моему мнению», или «Мне кажется» — плохая идея.
Проверьте дважды. Убедитесь, что описанный вами сценарий приводит к багу и любой другой специалист повторит его, если пройдет тот же путь.
YouTube
Заключение
Составление bug report не требует особых навыков. Делайте документ таким, чтобы он был понятен. Если вы разработчик, просите от коллег составлять bug report по принципу, описанному в статье. Тогда вы сможете быстро находить и исправлять собственные ошибки в коде.
