Тестировщик обнаруживает дефект на продакшене, открывает трекер, чтобы завести тикет - и натыкается на знакомое: этот баг уже заводили. Восемь месяцев назад. Закрыт со статусом «не воспроизводится». Автор закрытия уволился. Комментариев нет. Шагов воспроизведения нет. Тикет создаётся заново - третий раз за два года.
Призрак из трекера: почему баги возвращаются
Это не редкая история. В энтерпрайзе такой сценарий повторяется регулярно, и каждый цикл стоит бизнесу денег. Потерянное время инженеров, сгоревшие SLA, разъярённые клиенты - всё это прямые последствия сломанного процесса баг-трекинга, а не плохого инструмента.
Корень проблемы редко в самом трекере. Чаще - в отсутствии жёстких правил жизненного цикла дефекта. Баг закрыли без объяснений, потому что никто не потребовал задокументировать причину. Тикет завели повторно, потому что поиск по трекеру никто не проверил. Приоритет выставил сам автор на эмоциях, а не процесс приоритизации.
Три симптома умирающего процесса
Можно долго спорить о выборе платформы - Jira, Redmine, GitLab Issues или что-то тяжелее. Но прежде чем выбирать инструмент, стоит честно ответить: работает ли вообще процесс? Есть три признака, что он давно сломан.
- Баги живут в корпоративном чате. Тред уехал вверх - дефект забыт. Всплывает через месяц на проде.
- Один дефект заведён трижды разными тестировщиками. Три оценки трудозатрат, три приоритета, хаос в бэклоге.
- Критичный тикет полгода висит без движения, потому что статус «P1» присвоил сам репортер, а не регламент.
Интересно, что схожая логика работает и в других областях, где важна правильная приоритизация - например, составляя mlbb тир лист, аналитики тоже сталкиваются с тем, что субъективная оценка без чётких критериев быстро превращается в мусор. Там, где нет системы, побеждает хаос.
Что реально помогает: не платформа, а дисциплина
Нормальный баг-трекинг - это прежде всего процесс. Инструмент лишь помогает его удерживать. Жизненный цикл дефекта должен быть однозначным: завели, прошли триаж, приоритизировали, взяли в спринт, верифицировали, закрыли. У каждого шага - ответственный.
Решение о починке - продуктовое, не техническое. Product Owner берёт на себя trade-off: фикс бага против срока новой фичи. Если этого не происходит, бэклог превращается в кладбище тикетов с вечными «критичными» дефектами.
Правило трёх спринтов работает только при автоматизации. Вручную никто не будет чистить протухшие тикеты. Нужны триггеры, которые принудительно закрывают старьё со статусом Won't Fix - иначе правило остаётся красивой строчкой в вики.
Цена бездействия
Один баг, заведённый трижды за два года, - это не курьёз. Это диагноз. Каждый цикл - инженерные часы на повторное расследование, дубли в бэклоге, merge-конфликты от параллельных фиксов. Умножьте на количество подобных дефектов в системе, и счёт быстро уходит в миллионы рублей скрытых потерь. Баг-трекинг - не «куда записывать баги». Это единственное, что не даёт им возвращаться снова и снова.
