Заведённый баг-репорт не исчезает и не чинится мгновенно — он проходит путь: его посмотрели, взяли в работу, починили, проверили, закрыли. Этот путь называют жизненным циклом бага, а его этапы — статусами. Живёт всё это в баг-трекере — программе, где команда ведёт задачи и дефекты (самый известный — Jira).
Понимать цикл и статусы нужно, чтобы говорить с командой на одном языке и знать, на каком этапе ваш баг и что от вас сейчас требуется.
Обычный путь — Open → In Progress → Fixed → Closed, но после Fixed ход ваш: баг не ушёл — Reopened, и он снова у разработчика, круг может повториться не раз. Часть багов до работы не доходит вовсе: Rejected, Duplicate, Cannot Reproduce.
Типичные статусы бага
Названия чуть разнятся от команды к команде, но логика одна:
- Open / New (открыт / новый). Вы завели баг, его ещё никто не взял.
- In Progress (в работе). Разработчик взял баг и чинит.
- Fixed / Resolved (исправлен). Разработчик говорит «починил» и передаёт вам на проверку. Внимание: это ещё не конец — это сигнал вам перепроверить.
- Closed (закрыт). Вы перепроверили, баг ушёл — дефект закрыт. Это финал.
- Reopened (переоткрыт). Вы перепроверили, а баг всё ещё есть (или вернулся) — открываете заново, возвращаете разработчику.
Отдельно бывают «отказные» статусы, когда баг не будут чинить:
- Rejected / Won't Fix (отклонён / не будем чинить). Команда решила, что это не баг или чинить не стоит.
- Duplicate (дубликат). Такой баг уже заведён кем-то раньше.
- Cannot Reproduce (не воспроизводится). По вашим шагам повторить не удалось — обычно из-за неполного репорта.
Как баг ходит по кругу
Обычный путь: вы завели (Open) → разработчик взял (In Progress) → починил (Fixed) → вы перепроверили. Дальше развилка: ушёл — Closed; не ушёл — Reopened, и он возвращается разработчику. Так может повториться не раз.
Два важных момента:
- Статус Fixed — это ваш ход, а не конец. Разработчик лишь заявил, что починил. Пока вы не проверили и не закрыли, баг не закрыт. Проверку исправленного бага называют повторным тестированием (re-test).
- После проверки бага загляните рядом. Починка могла задеть соседнее — это регресс. «Баг ушёл, но сломалось другое» — частая история.
Разбор дефектов: кто решает судьбу бага
Между «завели» и «взяли в работу» есть шаг, которого в списке статусов не видно. За неделю багов набирается больше, чем команда успеет починить до выпуска, и кто-то должен решить, что чинят сейчас, что потом, а что не чинят вообще. Эту короткую регулярную встречу называют разбором дефектов (defect triage).
Собираются обычно трое. Тестировщик объясняет находку и отвечает на вопросы — что именно ломается и как часто. Разработчик или руководитель команды оценивает, сколько стоит починка и что она может задеть. Менеджер или владелец продукта говорит, чем это грозит покупателям. По каждому новому багу решают четыре вещи: настоящий ли это дефект (иначе Rejected или Duplicate), в какой выпуск он попадает, кто им займётся и с каким приоритетом.
Простановка приоритета — часть разбора, но не он сам. Приоритет ставят по одному багу и по его свойствам: насколько сильно ломается и сколько покупателей задето. Разбор смотрит на все баги разом и добавляет то, чего в отдельной карточке не видно: сколько у команды рук до выпуска, что чинят первым при равном приоритете и что сознательно оставляют до следующего раза. Поэтому «высокий приоритет» и «чиним в этом выпуске» — разные решения, и второе принимают вместе.
Что такое баг-трекер
Баг-трекер (или таск-трекер) — это система, где команда хранит все задачи и баги: кто автор, кто исполнитель, статус, приоритет, история изменений, комментарии, вложения. Всё в одном месте и не теряется. Самый распространённый — Jira; есть и другие (YouTrack, Azure DevOps, GitLab Issues, Trello и т. п.), но логика везде похожа.
В трекере вы будете:
- Заводить баги — по сути, оформлять баг-репорт в виде карточки.
- Видеть свои и чужие задачи — что в работе, что на проверке.
- Менять статусы — переводить баг в Closed или Reopened после проверки.
- Общаться в комментариях — уточнять у разработчика, отвечать на вопросы.
- Фильтровать и искать — например, «все открытые баги с высоким приоритетом по моему проекту».
Отдельно стоит запомнить: у бага и обычной задачи (новой функции) в трекере путь похож, но баг — это про «что-то сломано», а задача — про «надо сделать». Часто баги привязывают к той функции или спринту, где их нашли.
Где это применяется
Трекер — ваше основное рабочее место. Рабочий день тестировщика во многом состоит из действий в нём: завести баг, перевести проверенный в Closed, переоткрыть невоспроизведённую починку, ответить на вопрос в комментарии, посмотреть, что осталось до релиза. Понимание статусов помогает не терять баги в воздухе и всегда знать, чей сейчас ход — ваш или разработчика.
Где спотыкаются чаще всего:
- Считают, что после Fixed можно расслабиться. Нет — это сигнал перепроверить. Пока не закрыли сами, баг не закрыт.
- Закрывают баг, не проверив рядом (регресс) — и пропускают то, что сломала починка.
- Молча переоткрывают баг без пояснения. Всегда пишите в комментарии, что именно не так и по каким шагам, — иначе разработчик снова не воспроизведёт.
- Заводят дубликаты, не поискав, нет ли уже такого бага.
Коротко
- Жизненный цикл бага — это последовательность статусов: Open, In Progress, Fixed, Closed, а при неудачной проверке — Reopened, и круг повторяется.
- Fixed — не конец, а ваш ход: разработчик лишь заявил, что починил; пока вы не перепроверили и не закрыли, баг открыт.
- Отказные статусы — Rejected, Duplicate, Cannot Reproduce: баг закрыт без починки, и последний почти всегда означает неполный репорт.
- Разбор дефектов (defect triage) решает по каждому багу четыре вещи: дефект ли это, в какой выпуск, кто чинит и с каким приоритетом.
- Приоритет ставят по свойствам одного бага, разбор смотрит на все баги сразу и на руки команды до выпуска — поэтому «высокий приоритет» и «чиним в этом выпуске» решения разные.
- После проверки исправленного загляните рядом: починка часто ломает соседнее, и это уже регресс.
Что почитать дальше
- Качество баг-репорта — как писать так, чтобы баг не вернулся с «не воспроизводится».
- Что такое баг: severity и priority — откуда берётся вес дефекта, с которым приходят на разбор.
- Тест-менеджмент: TestRail, Qase, Zephyr — где живут кейсы и прогоны рядом с трекером.
- Отчёт о результатах тестирования и метрики — как статусы и сроки превращаются в картину для выпуска.