Совсем недавно я публиковал в паблике вопрос на соответствующую тему и совсем не зря. Такой вопрос в той или иной вариации часто задают на собеседованиях.

Давайте разбираться, когда же стоит оформлять найденную ошибку, то есть писать баг-репорт.

У нас может быть несколько различных вариантов развития событий:
1. Сначала протестировали, потом оформили баг-репорты на найденные ошибки.
2. Тестируем и не оформляем баг-репорты, говорим о них устно и программисты исправляют.
3. Тестируем и оформляем баг-репорты сразу же после их нахождения.

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

Сначала протестировали, потом оформили баг-репорты на найденные ошибки

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

Такой подход хорош тем, что тестировщик не отвлекается на оформление ошибок. Все его внимание сосредоточено на тестировании. Иногда этот подход достаточно эффективен (например, в сессионном тестировании). Но у него есть и свои минусы.

Во-первых, специалист может элементарно забыть некоторые найденные баги. Все мы люди и не можем помнить все и всегда.

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

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

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

Не оформляем баг-репорты, говорим о них устно или в чате

Данный подход подразумевает, что тестировщик просто пишет разработчику в личку, в чат или говорит устно о том, что нашел баг. Разработчик его сразу же исправляет, после чего специалист по тестированию снова его проверяет. Баг-репорт в системе баг-трекинга не оформляется.

Чем может быть хорош данный подход? Время жизненного цикла бага сокращается, так как нет этапа оформления дефекта.

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

Также это повышает риск пропустить какую-либо проблему в процессах тестирования или разработки. Если тестировщик и программист устно фиксят много проблем в текстах (опечатки, ошибки и т.д.), то лид просто не заметит этого.

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

Такой подход несет в себе существенные риски и лучше им пользоваться только в самых критичных ситуациях, когда нет времени на оформление баг-репорта. Но потом все-таки лучше оформить найденные дефекты в системе баг-трекинга.

Обычно он используется в маленьких компаниях, где багов мало и смысла разворачивать систему баг-трекинга нет.

Оформляем баг-репорты сразу после их нахождения

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

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

Минусы.
Тратится время на оформление баг-репортов, специалист по тестированию отвлекается от непосредственной проверки системы.

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

***

Теперь вернемся к нашему вопросу. Как мы видим, желательно регистрировать найденный баг в системе баг-трекинга вне зависимости от того, был он исправлен до оформления или нет. Многие из вас верно отметили, что это поможет учесть время работы программиста. Также это обязательно нужно, если данные показатели используются для метрик. Да и кто потом будет контролировать пофиксил ли разработчик баг или нет? Без оформления он может легко потеряться.

Ну и бывают случаи (срочный релиз, совсем небольшой проект и т.п.), когда баги не регистрируются в системе. Опять же, если нет времени на оформлении прямо сейчас, то никто не мешает оформить баг-репорт после проверки.

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

А какие вы видите плюсы и минусы в подходах? Может быть вы знаете еще подходы к учету найденных багов?