June 8, 2023
Про работу с баг-трекером
Сообщать о багах надо так, чтобы к тебе в последствии возникло как можно меньше вопросов. Проще говоря — нужно подробно описать проблему и при каких обстоятельствах она возникла. В этой заметке разберём, что и как надо указать/прикрепить оформляя ошибку в баг-трекер.
Определение и функции баг-трекера
Баг-трекер – хранилище истории изменений в ПО.
Каждый из членов команды разработки использует баг-трекер для своих целей:
- Руководитель проекта.
Следит за выполнением задач, количеством ошибок и решает, что и когда будет исправляться. Часть обязанностей он может делегировать. - Аналитик.
Формулирует задачи: требования, описание сценариев использования функциональности. - Разработчик.
Использует баг-трекер как список дел. Он реализует функциональность, описанную в порученной ему задаче, или исправляет ошибку, которую ему назначили. - Тестировщик.
Проверяет реализованные разработчиком задачи, регистрирует дефекты, которые обнаружены в ПО или получены от пользователей.
Обязательные атрибуты ошибки в баг-трекере
- Тип.
Поле, которое отличает ошибку от задач и доработок. - Заголовок.
Кратко, по принципу «Где? Что? Когда?». - Шаги воспроизведения:
- Каждый шаг содержит одно действие.
- Шаг должен говорить, что нужно сделать, а не почему и зачем.
- Шаг лучше всего начинать с глагола, причем в форме инфинитива (пример, «Нажать кнопку»).
- Не описывать в шагах эмоции или личное восприятие.
- Соблюдать определенную детальность в шагах.
- Нужно описать, как привести систему в состояние ошибки.
- Каждый шаг обязателен для воспроизведения ошибки.
- Присваивайте шагам порядковые номера.
- Окружение.
Разрешение экрана, версия и название браузера, и т.д. - Версия.
Сообщив разработчику версию ПО, вы поможете определить направление поисков бага. Или сможете порадовать его тем, что нашли ошибку в более ранней версии ПО, и она уже исправлена. - Градация серьезности ошибки.
- Градация Приоритета дефекта.
- Поле «Назначен на».
Здесь указывается, на кого задача назначена в текущий момент.
Жизненный цикл (workflow) ошибок
- Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
- Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
- Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)
- Новый (New).
Найденный баг вносится в специальную систему, где хранятся баг-репорты. С этого момента баг начинает официально существовать. Далее его статус меняется на Отказ (Rejected) или на Назначен (Assigned). - Отказ (Rejected).
Пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть некачественное описание дефекта, такой дефект уже существует (дубликат), невозможность воспроизвести дефект. Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными. После этого дефект Закрывается (Closed) или дополняется комментариями по данному дефекту и переводится заново в состояние Назначен(Assigned). - Назначен (Assigned).
Дефект просмотрен и открыт (то есть признан для исправления). - Решен (Fixed).
Дефект исправили и он в этом состоянии требует перепроверки тестировщиком.
После проверки ошибки, дефект переводится в состояние Переоткрыт (Re-opened) (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.