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