Как правильно заводить баги

Главная цель создания бага (дефекта) – рассказать “миру” об ошибке, которую вы нашли. И важно, чтобы тот, кто будет исправлять и проверять этот баг, понял вас с первого раза. Плохо описанный баг вызывает лишние телодвижения и обсуждения, которых можно избежать и сэкономить время для полезных задач.

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

И да, в этой статье баг-репорт = баг = дефект = ошибка. Кто-то эти понятия разделяет, кто-то использует как синонимы. Мы решили использовать второй вариант синонимов.

У дефектов есть следующие атрибуты, которые нужно заполнять:

1. Заголовок

Заголовок должен быть кратким и лаконичным. После его прочтения все должны понимать, в чем заключается ошибка. Заголовок полезно начинать с глагола (не работает, не отображается). Далее как в игре – что, где, когда.

• Глагол – Не работает
• Что – кнопка сохранения нового пароля
• Где – в настройках учетной записи
• Когда – после ввода нового пароля и подтверждения

или

Не отображается сообщение об успешной смене Email после перехода по ссылке из письма в IE10

Согласитесь такой заголовок гораздо понятнее, чем “Не работает кнопка” или “Сообщение о смене email”. Часто такие заголовки пишут тестировщики, и чтобы понять суть ошибки приходится читать детальное описания бага.

Но ведь разработчики все равно будут читать детали бага! – возразите вы и будете правы. Разработчики в любом случае читают баг целиком. Зачем тогда писать красивый заголовок? А вот зачем:

• Правильное название бага облегчает его поиск.

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

• Отчеты по найденным багам более понятны

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

2. Шаги для воспроизведения

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

Пример “все шаги в одном”:

Шаги для воспроизведения: Войти в профиль аккаунта и там в настройках изменить email и сохранить

Пример “пошагово”:

1. Войти в профиль аккаунта
2. Перейти в раздел Настройки
3. Ввести  новый email в поле для смены email
4. Нажать на кнопку Сохранить

Строгих правил конечно нет, но представление по пунктам понятнее и легче воспринимается при чтении.

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

3. Ожидаемый результат

Что должно произойти, согласно требованиям. Как должна отработать программа в этом случае. Обязательный пункт, даже если он выглядит очевидным для вас. Разработчик может не понять, как же должно быть, поленится смотреть в требованиях и вернет баг вам для уточнения. Чтобы избежать такого “пинг-понга” лучше сразу писать ожидаемый результат (или модно по-английски Expected Result)

4. Фактический результат

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

5. Окружение

Здесь указывается:

• браузер и операционная система
• боевой или тестовый стенд

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

6. Версия билда/сборки, в которой найден баг

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

7. Тестовые данные

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

8. Автор бага

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

9. Исполнитель

Тот, на кого назначена бага. Это либо аналитик для правки требований, или разработчик для правки кода, или дизайнер для правки макетов, или тестировщик для проверки бага.

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

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

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

Если мы не знаем, в каком модуле ошибка и матрицы ответственности у нас нет? Есть другой вариант

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

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

10. Скриншоты, видео

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

11. Лог-файлы или трейсы

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

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

12. Критичность / Серьезность

Серьезность (Severity) — показывает влияние дефекта на работоспособность приложения и определяется тестировщиком.

Выделяют, как правило, от 3 от 5 степеней критичности.

Рассмотрим 4:

• S1 Critical — тестирование заблокировано
• S2 Major  — важная функция не работает
• S3 Minor — менее важная функция не работает
• S4 Trivial — проблема несущественна + косметические правки

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

• 1, 2, 3, 4
• Blocked / Critical / Major / Minor / Trivial
• Critical / High / Normal / Low

13. Приоритет

Приоритет (Priority) — это порядок, в котором дефекты должны быть исправлены. Определяются бизнесом (выставляет менеджер проекта или менеджер продукта). Чем выше стоит приоритет, тем скорее нужно исправить дефект.

• P1 Высокий (High) — исправить немедленно
• P2 Средний (Medium) — попозже
• P3 Низкий (Low) – в следующей пятилетке

Часто используют только 1 параметр – критичность – и часто в багтрекерах он называется приоритетом. Понятия схожие и многие путают.

14. И другие 🙂 В багтрекерах еще выделяют дополнительные поля, такие как:

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

Так вот, мы рассмотрели основные важные атрибуты бага, которые нужно описывать.

Багтрекеры позволяют добавлять новые поля к багу, если они необходимы для работы. Следите за своим проектом и решайте, какую информацию именно для ваших менеджеров и разработчиков нужно донести. И конечно перед сохранением бага, прочитайте еще раз, что получилось, а понял бы вас человек, который 1 день на проекте? Все ли понятно в шагах, все ли важные поля вы заполнили? Если ввести заведение хороших багов в привычку, увидите, сколько времени вы экономите на переписках и выяснение деталей с разработчиками.