Баг со статусом «Fixed» который сразу переходит в «Closed» минуя «Verified»: вот как регрессии попадают в продакшн. Баг в статусе «Assigned» три спринта подряд: это тикет за которым никто не следит, а не фикс в процессе. Здесь разобраны все статусы жизненного цикла бага, кто владеет каждой передачей, и что делать когда баги зависают, помечаются Won't Fix, или возвращаются после того как ты уже их проверил.
Стандартные статусы и кто за них отвечает
В каждой системе трекинга багов свои метки, но базовые статусы универсальны. Понимание кто держит ответственность на каждом этапе говорит тебе когда действовать, а когда ждать.
New обозначает момент когда ты заводишь тикет. Ещё ничего не произошло. Баг существует на бумаге, но никто не взял обязательство его исправить. Твоя задача здесь: сделать репорт безупречным. Чёткий заголовок, точные шаги воспроизведения, ожидаемое vs фактическое, severity, вложения. Плохо написанный «New» баг будет висеть в тriage-limbo потому что тот кто возьмёт его не сможет воспроизвести. Assigned означает что кто-то из команды разработки владеет тикетом. Это не значит что они на него смотрели. Не значит что согласны что это баг. Значит что имя прикреплено. Здесь баги стареют. Подробнее об этом ниже. In Progress означает что идёт активная работа. Разработчик воспроизводит, исследует, или пишет фикс. Твоя задача как QA здесь: доступность. если у разработчика есть вопросы по среде воспроизведения или граничным случаям, отвечай быстро. Задержки здесь добавляют груз спринту. In Review означает что фикс написан и ждёт code review или согласования. Некоторые команды объединяют это с состоянием «Ready for QA» которое сигнализирует что сборка готова для верификации. Знай какой воркфлоу использует твоя команда: это различие важно для планирования спринта. Fixed (или «Ready for Testing»): передача обратно тебе. Разработчик считает что проблема решена. Теперь твоя очередь. Верифицируй по исходным шагам воспроизведения точно. Не импровизируй новый тестовый путь. Сначала подтверди что конкретный сценарий из тикета решён, потом расширяй до смежных случаев. Verified означает что ты подтвердил: фикс работает как описано. Исходный дефект исчез. Очевидные регрессионные пути проверены. Это твоя подпись под принятием работы. Closed означает что верифицированный баг принят и закрыт. В большинстве команд это делает лид QA, scrum-мастер, или происходит автоматически при закрытии спринта. Баг никогда не должен переходить из Fixed в Closed минуя Verified. Именно пропуск этого шага пускает регрессии в продакшн.Статус Rejected означает что команда решила: reported behaviour на самом деле корректен. Либо ожидаемый результат в репорте был неверным, либо поведение намеренное по дизайну, либо репортер неправильно понял требование. Rejected не означает что ты был небрежен. Это легитимный исход. Задокументируй почему был отклонён, чтобы будущие тестировщики не завели тот же тикет повторно.
Deferred означает что баг реален и признан, но не исправляется в этом спринте или релизе. Уходит в бэклог. Будет ли он когда-либо исправлен зависит от того насколько убедительно ты за него аргументируешь. Won't Fix означает постоянный Deferred. Команда решила что этот дефект не стоит усилий на исправление. Иногда это правильное решение. Иногда нет. То как ты реагируешь определяет станет ли это проблемой позже.Won't Fix и Deferred: как аргументировать без конфронтации
Реальный сценарий. Заводишь баг: «На странице оформления заказа применение промокода после выбора способа доставки сбрасывает выбор доставки на вариант по умолчанию». PM разбирает его на triage и помечает Deferred. Комментарий: «Низкое влияние, граничный случай, мало пользователей сталкивается».
Большинство QA-инженеров либо молча принимают это, либо спорят эмоционально. Ни то ни другое не работает.
Правильный подход: переформулировать разговор вокруг данных и пользовательских путей, а не личного мнения. Спроси: сколько сессий оформления заказа в неделю включают промокод? Показывает ли аналитика скачки отказов на этом шаге? Приводит ли сброс доставки к отправке заказов по неверному адресу?
Если таких данных нет, скажи об этом и спроси кто может их выгрузить. «Хочу понять реальную частоту прежде чем закрывать. Можем выгрузить данные воронки оформления за последние 30 дней?» Это разумный запрос, не спор.
Если PM всё равно хочет отложить после просмотра данных, задокументируй риск явно в тикете. Напиши: «Риск принят: пользователи применяющие промокоды могут непреднамеренно выбрать неверный способ доставки. Влияние: потенциальное неверное выполнение заказов». Затем закрывай. Ты выполнил свою работу. Если проблема всплывёт после релиза, будет чёткая запись что риск был поднят и задокументирован.
Переоткрытие багов без скандала
Баг вернулся. Ты верифицировал его две недели назад, он стоит в Closed, и теперь тот же симптом появляется в продакшне. Нужно переоткрыть, но разработчик который его чинил заметит, и никому не нравится когда их работу вызывают обратно.
Правило простое: переоткрывай только когда можешь доказать что исходный сценарий снова не работает. Не «что-то похожее», не «может быть связано». Точные исходные шаги воспроизведения, та же среда, тот же результат.
Когда переоткрываешь, добавь комментарий до изменения статуса. Включи: дату переоткрытия, новый скриншот или запись, точные шаги воспроизведения которые ты запускал (даже если идентичны исходным), и видишь ли ты тот же симптом или новую вариацию. Если это новая вариация на том же компоненте: заводи другой баг, не переоткрывай.
Допустим, ты верифицировал что баг «промокод сбрасывает доставку» был исправлен в v2.8.1. В v2.8.3, после отгрузки новой фичи вокруг флоу оформления заказа, баг вернулся. Переоткрываешь, прикладываешь запись, и пишешь: «Регрессия внесена в v2.8.3. Фикс присутствовал в сборке v2.8.1, отсутствует в текущей. Переоткрываю с новой записью».
Такая формулировка делает две вещи. Признаёт что исходный фикс был корректным. Указывает на новую регрессию а не намекает что разработчик не починил правильно с первого раза. Это различие важно для рабочих отношений.
Дублирующиеся баги: выявление и аккуратное слияние
В любом активном продукте несколько тестировщиков могут независимо завести один и тот же баг, особенно вокруг только что отгруженных фич. Раннее выявление дублей экономит время triage и предотвращает разрозненные усилия разработчиков.
Перед заведением нового бага поищи в трекере симптом. Сначала по компоненту (checkout, login, upload), затем по ключевым словам из сообщения об ошибке или поведения. Если работаешь в Jira, используй панель «Similar Issues»: она ищет автоматически при создании тикета.
Если нашёл дубль после заведения, отметь свой как дубль оригинала (не наоборот, если только твой явно не более детальный). Добавь комментарий: «Помечаю как дубль PROJ-144. Тот же путь воспроизведения, тот же симптом. Добавляю свои скриншоты в оригинальный тикет, вдруг помогут».
Затем перейди в оригинальный тикет и реально добавь ценность из своего дубля. Возможно у тебя более чёткое видео или другая версия браузера которая воспроизводит баг. Эта информация полезна даже если твой тикет закрыт как дубль.
Одно что стоит избегать: слияние багов которые выглядят одинаково но таковыми не являются. Если два тикета имеют одно сообщение об ошибке но разные триггеры, возможно это два отдельных дефекта. Проверь первопричину перед слиянием. Разработчик который исправляет один баг на основе объединённого репорта и упускает второй триггер не будет доволен обнаружению этого в продакшне.
Старение багов: что делать когда Assigned ничего не значит
Ты завёл баг. Его разобрали на triage, назначили разработчику, и дальше три спринта ничего. Sprint review приходит и уходит, никакого упоминания. Тикет висит в «Assigned» как ископаемое.
Это одна из наиболее распространённых QA-фрустраций, и правильный ответ: visibility, а не нытьё.
Сначала посмотри на баг сам. Приоритет актуален? Он всё ещё блокирует что-либо? Если контекст изменился и баг теперь менее релевантен, скорректируй приоритет и добавь комментарий. Низкоприоритетный баг висящий три спринта менее тревожен чем средний.
Если приоритет актуален и баг всё ещё важен, подними его явно на sprint review. Не как жалобу, а как риск-айтем. «У нас PROJ-188 висит в Assigned три спринта. Затрагивает функцию экспорта в CSV которую наши enterprise-пользователи часто упоминают. Хочу поднять это для следующего спринта пока не стало клиентской эскалацией».
Большинство состарившихся багов умирают потому что никто не поднимал их повторно. Твои sprint review и backlog refinement-встречи существуют именно для этого.
Если баг действительно не должен быть исправлен в текущем роадмапе, попроси официально перевести его в Deferred с задокументированной причиной. Честный Deferred лучше зомби-тикета в Assigned: даёт команде чёткий сигнал и предотвращает ложное представление о количестве открытых багов.
Jira, Linear и GitHub Issues в 2026
Логика воркфлоу выше применима везде, но инструменты с которыми работаешь имеют существенные различия в реализации переходов между статусами.
Jira остаётся стандартом в средних и крупных enterprise-командах. В 2026 году это уже третье поколение воркфлоу после разделения на company-managed и team-managed. Статусы багов в Jira полностью настраиваемы, что означает: каждая команда использует свой набор статусов из описанных выше. Первая неделя на новой команде использующей Jira должна включать понимание что конкретно означают их статусы воркфлоу. Не предполагай что «In Progress» означает активную работу разработчика. В некоторых настройках Jira это означает «признан но не начат». Смотри документацию воркфлоу или спрашивай напрямую. Linear сейчас стандарт в большинстве ранних и растущих стартапов. Использует более простую модель статусов: No Status, Backlog, Todo, In Progress, In Review, Done, Cancelled. Выделенного статуса «Verified» нет по умолчанию: верификация QA либо происходит внутри «In Review» либо команды добавляют кастомный статус. Если заходишь в команду на Linear, проверь есть ли шаг верификации QA в воркфлоу. Если нет, предложи добавить. Тикет идущий из «In Review» в «Done» без подписи тестировщика: паттерн который рано или поздно отгружает непроверенные фиксы. GitHub Issues распространён в open-source и продуктах для разработчиков. Нативная модель статусов: просто Open и Closed, всё остальное через метки. Большинство команд которые делают структурированное QA на GitHub Issues используют метки вродеstatus: ready for QA, status: verified, и milestones для отслеживания скоупа релиза. Трение здесь в том что GitHub Issues не имеет enforced воркфлоу: дисциплина полностью ручная. В команде где этой дисциплины нет, баги переходят из Open в Closed без какого-либо шага верификации.
Общее во всём: в каком бы инструменте ты ни был, разберись в реальном воркфлоу который использует твоя команда, а не в том что инструмент поддерживает по умолчанию. Статусы жизненного цикла существуют независимо от того какие метки использует твой трекер.
Метрики: цифры которые показывают работает ли процесс
Отслеживать статусы багов по отдельности полезно. Отслеживать паттерны по всем багам говорит о том здоров ли твой процесс качества.
Defect escape rate измеряет процент багов найденных в продакшне от общего числа найденных багов. Если команда находит 30% багов после релиза, процесс тестирования недостаточно ловит до отгрузки. Формула: (баги найденные после релиза) / (всего найденных багов) × 100. Здоровая ставка для большинства команд: ниже 15%. Если у тебя выше, смотри где в цикле разработки вносятся баги и где заканчивается покрытие тестирования. Mean time to resolve (MTTR) измеряет среднее время от заведения бага до его закрытия. Растущий MTTR сигнализирует об одном из трёх: команде не хватает ресурсов для объёма багов, баги заводятся с низким качеством (дольше на triage и воспроизведение), или конкретные компоненты генерируют избыточную плотность дефектов. Отслеживай MTTR по компоненту чтобы найти горячие точки. Отчёт о старении открытых багов показывает именно то что следует из названия: вид всех открытых багов отсортированных по времени нахождения в этом статусе, сгруппированных по статусу. Полезная версия сегментирована по статусу. Куча в «New» означает что triage не справляется. Куча в «Assigned» означает что разработчики не берут баги. Куча в «Fixed» означает что QA недостаточно быстро верифицирует. Каждый статус рассказывает разную историю о том где узкое место.Эти три метрики вместе дают достаточно полную картину здоровья жизненного цикла багов. Запускай их ежемесячно, а не только в конце релизного цикла.
Что сделать прямо сейчас
Зайди в свой трекер багов и подними все тикеты назначенные тебе или заведённые тобой которые не в Closed или Won't Fix. Для каждого: верен ли статус? Актуален ли приоритет с учётом текущего спринта? Есть ли тикеты которые висят в одном статусе больше двух спринтов без комментария?
Для каждого состарившегося тикета добавь сегодня однострочный комментарий: либо проверку статуса если она нужна («Всё ещё актуально: функция экспорта в скоупе, поднимаю на следующем sprint review»), либо явный запрос на Defer если больше не актуален («Контекст изменился с момента заведения: этот экран убрали в v2.9. Рекомендую закрыть»).
Этот один проход по открытым багам делает три вещи: очищает ментальный бэклог, даёт команде точную информацию о том что реально открыто, и показывает что ты активно управляешь качеством, а не просто заводишь тикеты и идёшь дальше.
Жизненный цикл бага: не бюрократия. Это механизм которым находка превращается в фикс. Каждый переход статуса: передача, и за каждой передачей нужен кто-то кто за ней следит. Это и есть работа.
→ See also: Анатомия баг-репорта, который исправят: структура и примеры | Severity vs Priority: навык триажа багов, который продвигает по карьере | Как писать тест-кейсы: формат, примеры и частые ошибки
