Баг-трекинг: почему баги возвращаются на прод и какая система это лечит

Тестировщик находит баг в проде и идёт заводить тикет. Поиск по трекеру показывает: этот баг уже заводили — восемь месяцев назад. Закрыт со статусом «не воспроизводится». Автор закрытия уволился, комментариев нет, шагов воспроизведения нет. Тикет заводится заново — третий раз за два года.

Знакомая картина? В энтерпрайзе она стоит бизнесу миллионов рублей на потерянном времени и сгоревших SLA.

Баг-трекинг — это не «куда записывать баги». Это процесс, который не даёт им возвращаться: с понятным жизненным циклом, жесткой ответственностью за «протухание» и связью дефекта с кодом и релизом. 

В статье разберём, как этот процесс устроен в суровой реальности, а не в учебниках по Agile, какие бывают баг-трекинговые системы — от GitLab Issues до Enterprise-платформ — и как выбрать свою, не переплатив за лишнее и не создав кладбище тикетов.

Зачем команде система отслеживания ошибок

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

Баг живёт в корп. чате

Репортнули в треде, тред уехал вверх, баг благополучно забыт. Через месяц он всплывает на проде, роняет критичный сервис, и никто не помнит, почему его не починили. Post-mortem пишется по логам из телеги — худший ночной кошмар безопасника и гарантия повторения инцидента.

Один дефект заведен трижды тремя тестировщиками

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

«Критичный» баг полгода висит без движения

Статус «Критичный» ему присвоил сам автор на эмоциях, а не процесс приоритизации. В итоге никто не обязан был на него реагировать, и он превратился в «вечный» тикет, деморализующий команду поддержки (L1/L2), которая устала отвечать клиентам «мы работаем над этим».

Базовые функции системы баг-трекинга

Давайте отделим маркетинговую шелуху от реальных потребностей эксплуатации. Вот таблица базовых функций, без которых система баг-трекинга превращается в инструмент создания хаоса.

Как баг-трекинг работает в живой команде

Баг-трекинг — это в первую очередь процесс и дисциплина. Инструмент лишь помогает его контролировать.

Жизненный цикл бага обычно выглядит так:

Заведен → Триаж → Приоритизация → Спринт → Верификация → Закрыт

В этом процессе у каждого своя роль. QA описывает баг максимально подробно, тимлид оценивает трудоемкость его исправления, а Product Owner (PO) решает «чинить или нет». Это важно понимать: решение о починке — это продуктовое решение, а не техническое. Бизнес должен взять на себя ответственность (trade-off) за то, что фикс бага отодвинет релиз новой фичи.

Правило трёх спринтов: если баг не взяли в работу за три спринта, его нужно закрывать (с соответствующим статусом, например, Won’t Fix). Иначе бэклог превратится в свалку надежд и разочарований. Но давайте честно: вручную это никто делать не будет. Нужна автоматизация (скрипты/триггеры), которая будет жестко убивать старые тикеты. Иначе это правило останется только на бумаге.

Пара антипаттернов, которые убивают процесс и выжигают инженеров:

• «Все баги P1»: когда каждый баг помечается как критичный, приоритеты перестают работать. Начинается синдром «волки-волки»: когда реально падает прод, команда реагирует вяло, думая, что это очередной съехавший пиксель;

• «Вася разберётся»: баг назначается на конкретного разработчика (например, потому что он писал этот код), даже если он перегружен. Задачи должны распределяться с учетом текущей загрузки, а не только экспертизы. Иначе у вас появляется Bus Factor = 1, и если Вася уйдет в отпуск (или уволится от переутомления), разработка встанет.

Подробный разбор процесса — с матрицей приоритизации Severity × Business Risk, SLA по уровням и шаблоном корректного Won’t Fix — в нашей статье «Баг завели. Баг забыли. Баг вернулся на прод».

Популярные баг-трекинговые системы

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

Статья опубликована в блоге SimpleOne, и SimpleOne SDLC входит в этот обзор. Мы знаем свой продукт лучше остальных — это влияет на оценку.

Тестируйте решения на собственном процессе и под собственной нагрузкой.

Классические баг-трекеры

В эту категорию входят решения, которые стояли у истоков баг-трекинга.

Jira

Легенда, о которой мы уже писали в статье «Аналоги Jira».

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

Redmine

Open-source классика. Если вы ищете замену, читайте наш материал «Аналоги Redmine». Подробный разбор плюсов и минусов, а также варианты миграции.

Bugzilla

• Для кого: команды, привыкшие к суровому open-source и не боящиеся спартанских условий. Идеально для тех, кто готов инвестировать время своих сисадминов в поддержку «бесплатного» софта;

• Сильная сторона: мощная система поиска и фильтрации. Отлично справляется с огромными объемами дефектов;

• Честный минус: интерфейс застрял в начале 2000-х. Новым сотрудникам будет больно, а UX напрямую влияет на то, будут ли разработчики вообще заполнять тикеты;

• Цена: бесплатно (Open Source), но TCO (Total Cost of Ownership) складывается из зарплат инженеров. На интеграцию Bugzilla с вашим CI/CD, настройку LDAP и поддержку древнего Perl-кода вы потратите десятки часов работы сеньора. Посчитайте его зарплату — и «бесплатный» трекер обойдется вам в миллион рублей скрытых костов в год.

Встроенные механизмы Git-платформ

GitLab Issues, GitHub Issues, Gitea

• Для кого: небольшие продуктовые команды разработчиков;

• Сильная сторона: теснейшая интеграция с кодом. Баг заводится там же, где лежит код, и связывается с коммитами автоматически. Никакой потери контекста;

• Честный минус: слабые возможности для настройки сложных workflow, кастомных полей и SLA. Нет полноценного управления инцидентами (если проблема пришла от живого клиента, а не от QA, вам придется жонглировать системами);

• Цена: от бесплатных тарифов до корпоративных подписок.

Для команды до 10 человек GitLab Issues может быть достаточно — и это нормально. Отдельная система имеет смысл, когда багов становится больше, чем держит голова тимлида, или когда дефекты приходят не только от QA, но и из поддержки. Не нужно забивать гвозди микроскопом Enterprise-систем, если у вас 3 разработчика.

Российские решения

SimpleOne SDLC

Платформа управления разработкой, где баг-трекинг — часть общего контура. Главное отличие от выделенных трекеров: дефект связан (подробнее почитать и посмотреть) не только с кодом, но и с поддержкой — инцидент из Service Desk превращается в баг бэклога с сохранением истории, без ручного переноса и потери контекста.

• Для кого: средние и крупные команды, где баги приходят из двух источников — от QA и от пользователей через поддержку (L1/L2) — и эти потоки нужно держать в одном процессе, соблюдая строгие корпоративные SLA;

• Сильная сторона: полный путь дефекта прослеживается насквозь: инцидент → баг → коммит → Merge Request → релиз. Вопрос «в какой версии починено и кто проверял» закрывается из карточки. Решает извечный конфликт между поддержкой (Ops) и разработкой (Dev);

• Честный минус: это тяжелая Enterprise-платформа, а не коробочный трекер — для команды из пяти человек с одним продуктом она избыточна; быстрый старт «за вечер» не ее сценарий. Интеграция процессов поддержки и разработки — это адская бюрократия. Как синхронизировать статусы? Что делать, если баг отклонили в разработке (Won’t Fix), а SLA по инциденту горит? Внедрение требует участия аналитиков и перестройки процессов (change management), чтобы настроить правильную приостановку таймеров SLA (SLA pause);

• Цена: по запросу, Enterprise-модель.

Яндекс Трекер

• Для кого: команды, уже использующие инфраструктуру Яндекса;

• Сильная сторона: надежность облачной инфраструктуры и глубокая интеграция с другими сервисами Яндекса;

• Честный минус: специфическая логика очередей, к которой нужно привыкнуть. Архитектура накладывает ограничения, если вы хотите строить сложные кастомные процессы;

• цена: бесплатно до 5 пользователей, далее от 258 руб. за пользователя.

Kaiten

• Для кого: Agile-команды, ценящие визуализацию и Kanban-подход;

• Сильная сторона: единое пространство досок, позволяющее видеть картину по всем проектам;

• Честный минус: ограниченные возможности для классического баг-трекинга (например, нет жесткого разделения Severity/Priority «из коробки», а значит, при росте бэклога начнется путаница);

• Цена: от 185 руб/мес за пользователя.

Чего не включили и почему

• YouTrack — JetBrains уже ограничивал российских пользователей, может продолжить. Рекомендовать как стратегический выбор не готовы.

• Azure DevOps — ушёл вместе с Microsoft. Мигрировать с одного ушедшего вендора на другого ушедшего — так себе план.

• Trello, Asana, Monday — это таск-трекеры, не баг-трекеры. Нет Severity/Priority, нет связи с релизами, нет SLA.

Как выбрать систему баг-трекинга под команду

Выбор системы должен диктоваться масштабом ваших проблем, а не маркетинговыми буклетами:

• До 10 человек: GitLab/GitHub Issues — и не усложняйте. Если вам хватает доски и комментариев, зачем городить энтерпрайз?

• 10–50 человек: выделенный трекер с раздельными Severity/Priority и связью с релизами (например, Яндекс Трекер). Вам нужно отличать критичные баги от визуальных недочетов, иначе команда потонет в микроменеджменте;

• 50+ человек или дефекты идут из поддержки: платформа, где баг-трекинг связан с ITSM-контуром (например, SimpleOne SDLC). Если баги сыплются из Service Desk, вам нужна прозрачная связь между инцидентом и задачей на исправление, иначе поддержка будет эскалировать всё подряд, а разработка будет отбиваться статусами «не воспроизводится».

Не выбирайте по демо. Возьмите свой самый запутанный баг — тот, который трижды переоткрывали, — и заведите его в систему на пилоте.

• Видно ли его историю?

• Связь с релизом?

• Коммит, который его чинил?

Если для ответа нужно открыть три вкладки — это не ваша система.

Заключение

Баг трекер — это инструмент, а процесс — главное. Система без триажа, ответственных и понятных правил превращается в кладбище тикетов независимо от того, сколько она стоит. Баг-трекинг должен работать на качество продукта, а не на статистику для красивых отчетов.

Каждый открытый баг — это скрытый налог на вашу velocity. Разработчики тратят время на скроллинг бэклога, триаж и чтение неактуальных тикетов. 500 висящих багов — это сотни человеко-часов в месяц, которые вы оплачиваете впустую.

Откройте свой трекер и посчитайте баги старше 90 дней без движения. Это и есть ответ на вопрос, работает ли у вас баг-трекинг — независимо от того, какая система установлена.

Сколько у вас сейчас открытых багов — и сколько из них вы реально планируете чинить? Делитесь в комментариях!