Что такое Bug и Bug Report в тестировании?

Что же такое баг?

Если кратко, то баг — это сленговое обозначение программной ошибки. В свою очередь, программная ошибка — это ошибка в программе или системе, из-за которой программа выдаёт неожиданное поведение и, как следствие, результат, который не соответствует плану. То есть bug — это расхождение ожидаемого и фактического результатов.

День рождения бага

Днём рождения первого компьютерного бага считается 9 сентября 1945 года. Это очень занимательная история. Суть в том, что разработчик обнаружил bug [жука] в ЭВМ, что и привело к некорректной работе последней.

Немного юмора

«Стакан наполовину полон», – говорит оптимист.

«Стакан наполовину пуст», – говорит пессимист.

«Стакан наполовину пуст и полон одновременно, потому что в стакане отверстие, которое соответствует спецификации», – говорит тестировщик.

С багами теперь стало понятнее, но что же такое bug report?

Bug report — это документ, описывающий и приоритизирующий обнаруженный баг, а также содействующий его устранению.

Цели bug report

Предоставить информацию о проблеме.
Приоритизировать её.
Содействовать устранению проблемы.

Одной из метрик эффективности работы тестировщика является количество bug report’ов, которые помогли команде разработки исправить ошибки в программе. Иными словами, таких ошибок, которые действительно негативно влияли на работу пользователей и были исправлены разработчиками.

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

Очень важный момент: тестировщику НЕ нужно писать 1000 бесполезных bug reports, а необходимо оформить этот отчёт таким образом, чтобы работа по устранению ошибок была эффективной.

Почему это важно?

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

Логика построения bug report

Эта логика очень проста:

Что сделали? (Шаги для воспроизведения).
Что получили? (Фактический результат).
Что ожидали получить? (Ожидаемый результат).

Уточним на примере

Я включил горячую воду, а она не течёт, хотя должна течь.

«Что сделали?» – включили горячую воду.

«Что получили?» – вода не течёт из крана.

«Что ожидали получить?» – вода должна течь.

Преимущества такой логики

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

Жизненный цикл bug report

Мы рассмотрим самый простой жизненный цикл, состоящий из следующих шагов:

Open. Обнаруженный баг занесён в баг-трекинговую систему.
In progress. Над проблемой была начата работа.
Fixed. Баг был исправлен.
Verified. Подтверждение того, что баг был исправлен.
Closed. Баг был закрыт.

Советы по созданию хорошего bug report 👌

Создавайте понятные для всех участников команды заголовки баг репорта.
Пользуйтесь поиском. Возможно, ваш коллега уже сделал такой же баг репорт. А зачем проекту и заказчику несколько одинаковых баг репортов?
Пользуйтесь форматированием для читабельности баг репорта.
После того как вы завели баг репорт, обязательно проинформируйте об этом всю команду и отдельно — человека, на котором лежит ответственность за исправление бага.