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

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

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

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

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

Как работать с баг-репортами

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

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

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

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

Дефекты также могут появляться после их исправления.

Добавление новых данных в баг-репорты — весьма хорошая практика в сравнении с процессом создания дубликатов.

Но что делать, если найденная проблема не очень ясна? Если самостоятельно не можете разобраться с видом ошибки, лучше спросить коллег.

Можно попробовать задать вопросы вида «Является ли это правильным? Что именно может вызывать подобное системное поведение? Может что-то было сделано не так?».

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

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

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

Почему баг-репорты настолько важны?

Когда команда тестировщиков в процессе проверки ПО находит ошибку, она в обязательном порядке должна создать о нем репорт.

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

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

1. Любой репорт автоматически создает обратную связь для проектной группы разработчиков ПО;
2. Репорт подразумевает содержание всей информации касательно бага в одном месте;
3. Репорт запросто можно отслеживать внутри инструмента менеджмента проектами;
4. Репорты можно приоритизировать относительно других задач;
5. Репорт содержит всю историю возникновения и жизнедеятельности дефекта.

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

Как правильно вести себя с баг-репортом?

Тут можно ответить всего одним словом — профессионально. Что это означает? Далее попробуем разобраться.

Классический баг-репорт — это конструкция формы для процесса коммуникации между сотрудниками.

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

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

Приоритезация баг-репорта на первом месте. Если вы нашли баг, его обязательно нужно исследовать.

Если вы думаете, что другое мнение вам поможет понять природу дефекта, спросите его.

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

Не стоит игнорировать дефекты, и не позволяйте им оставаться неделями в теле репорта.

Дефекты — это традиционно неожиданные, удивительные сюрпризы.

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

Любой артефакт баг-репорта — это, своего рода, живой файл, в который можно добавлять данные и выполнять обновление по ходу работы.

Работа с баг-репортами очень важна для максимально качественного функционирования всей проектной команды.

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