5 принципов при оформлении баг-репорта
- Перечитать оформление бага сразу после его написания, даже если вам кажется что вы оформили баг хорошо, все равно подумайте над тем, как можно улучшить описания, чтобы баг-репорт был еще более понятен разработчику
- Не дублируем баги, прежде чем оформлять баг-репорт, сделайте поиск, возможно кто то такой баг уже находил и оформил на него баг-репорт
- Исключить переход на личности, не нужно писать в баг-репорт разработчику, что он достал уже делать баги и фигово ходит, хладнокровно оформляем баг-репорт качественно с названием по принципу что, где, когда, с шагами, ФР и ОР.
- Локализуем баг на тестовом стенде, на тестовом аккаунте, с тестовыми данными и прикладываем всю эту информацию в баг-репорт, чтобы у разработчика не возникло никаких проблем с воспроизведением.
- 1 баг — 1 задача — 1 баг-репорт. Довольно холиварная тема, кому то удобнее работать как 1 баг — 1 задача, кому то удобно работать когда все баги указаны в виде списка в одной задаче и по мере фикса багов, можно вычеркивать пункты из списка, но на моем опыте как бы не договаривались с разработчиками, мы всегда приходим к тому, что каждый баг мы оформляем в отдельной задаче, в отдельном баг репорте. Представьте, что вы вначале вычеркнули баги из списка, а потом они появились снова, вы наверняка запутайтесь какие были были пофикшены, а какие нет, плюс многие баги вам нужно детально описывать и все их описывать в одной задаче довольно неудобно и громоздко.
Но, скажем, если вы нашли баги, которые касаются формы авторизации
- баг 1 — нельзя залогиниться
- баг 2 — едет верстка в поле логина
- баг 3 — едет верстка в поле пароля
- баг 4 — едет верстка на кнопке
В этом случае лучше всего оформить два баг-репорта, один баг-репорт на то, что нельзя залогиниться, другой баг-репорт на три бага верстки, так как все три бага относятся к форме логина и к верстке.