Баг-лист: шаблон и правила ведения в Google Таблицах

Баг-лист — это таблица, в которой собирают найденные ошибки проекта и ведут каждую до исправления и проверки. Мы вели его в Google Таблицах. Ниже — наши правила и шаблон.

Как описать баг

• Чётко, понятно, не двусмысленно: текущее состояние и как должно быть.
• Раздел и место, где находится баг. Если до него несколько действий — путь от и до, например «Главная. Новости. Детальная новости».
• Шаги воспроизведения, фактический и ожидаемый результат.
• Скриншот, на котором видно адрес и раздел, а место бага выделено. При тестировании веб-приложений держите открытой консоль разработчика и прикладывайте скриншот вкладок network и console.
• Окружение: устройство и разрешение в точках, а не пикселях, и браузер. Например, «Samsung Galaxy A23 384x734, Google Chrome».

Колонки баг-листа

1. Приоритет — ставит менеджер или тестировщик по согласованию с менеджером.
2. Место — заполняет автор бага.
3. Баг — формулировка с шагами, фактом и ожиданием.
4. Скриншот.
5. Кто написал.
6. Кто фиксит — разработчик, который берёт баг.
7. Время, план и время, факт — заполняет разработчик.
8. Комментарий — для обсуждения спорных моментов.
9. Статус: «Новый», «Отклонён», «В работе», «На МР», «Ждёт обновления дева», «На деве», «Открыт заново», «Проверен».
10. Окружение.

Цвета строк

• Белый — открытый баг, отвечает разработчик.
• Светло-зелёный — разработчик исправил, проверяет тестировщик или менеджер.
• Тёмно-зелёный — проверено и принято.
• Жёлтый — у разработчика вопрос или он считает, что это не баг. Вопрос обязательно пишется в комментарии. После ответа менеджер снимает выделение.
• Серый — не делаем: баг неактуален или это улучшение, которое уходит в бэклог.

Если исправление, по мнению разработчика, займёт больше часа, он сначала обсуждает решение с менеджером, а при необходимости — с другими разработчиками.

Приоритеты

• 0 — критические баги: сайт не работает или работает не так, как ожидается. 404 и 500 ошибки, не открывается раздел, не отправляются формы авторизации и регистрации.
• 1 — критичное юзабилити и забытые фичи.
• 2 — некритичные баги: например, попап не закрывается по тапу на свободную область.
• 3 — некритичное юзабилити: маленькая активная область кнопки.
• 4 — ошибки в текстах.
• 8 — хотелки: «Хорошо бы сделать эту кнопку синей, а не зелёной. Сделаем?»

Перед передачей разработчикам

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

Где взять шаблон

• Регламент: «Работа с баглистом в Google Sheets».
• Таблица: «Шаблон баглиста».

Оба документа присылает бот с регламентами. Работу с баг-листом новый менеджер изучает в первую неделю — см. план обучения менеджера проектов. Как проверять задачи спринта списком — в материале «Как составить чек-лист».

Вопросы и ответы

Что такое баг-лист?

Таблица, в которой собирают найденные ошибки проекта: место, описание, скриншот, автора, исполнителя, время, статус и приоритет. По ней баг ведут от находки до проверки.

Как правильно оформить баг?

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

Какие бывают приоритеты багов?

У нас: 0 — критические, 1 — критичное юзабилити и забытые фичи, 2 — некритичные баги, 3 — некритичное юзабилити, 4 — ошибки в текстах, 8 — хотелки.

Где скачать шаблон баг-листа?

Шаблон таблицы и регламент лежат в библиотеке документов, их бесплатно присылает бот с регламентами.