Как оформлять баги: отдельно от задач или с линковкой
Что проверяют
Понимаете ли вы, что от способа оформления зависит и статистика качества, и то, будет ли дефект вообще исправлен.
Как отвечать
Разделите по ситуациям, потому что единого правила нет.
Дефект найден в задаче, которая ещё не принята: он остаётся внутри задачи. Функция не сдана, значит это часть работы над ней, а не отдельный дефект. Обычно фиксируется комментарием или подзадачей и не попадает в статистику дефектов прода.
Дефект найден в уже выпущенной функциональности: заводится отдельная запись со ссылкой на исходную задачу или релиз. Отдельная запись нужна, потому что у неё своя жизнь: приоритет, исполнитель, срок, и она должна быть видна в отчётах.
Что даёт связывание:
- видно, какая задача породила дефект, и это материал для разбора причин;
- при повторении легко найти историю;
- по числу связанных дефектов видно проблемные места системы.
Что важно в самой записи независимо от способа: шаги воспроизведения, окружение и версия, ожидаемое и фактическое поведение, влияние на пользователя, доказательства. Приоритет обсуждается, а не назначается в одиночку.
Хорошо, если добавите про порядок в трекере: единый шаблон, обязательные поля, метки по компонентам, регулярный разбор накопленных дефектов. Иначе через год половина записей это неподтверждённые и дублирующиеся.
Где спотыкаются
Заводят отдельные записи на всё подряд, включая замечания по невыпущенной функции, и раздувают статистику.
Прячут дефекты в комментариях к задачам, после чего они теряются при закрытии задачи.
Не связывают дефект с релизом, и разобрать причину появления потом невозможно.