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

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

Баг-трекер (bug tracker, issue tracker) — система, где каждый дефект живёт как отдельная задача: со статусом, историей изменений, ответственным и сроком. TMS (Test Management System, система управления тестами) — система, где живут тест-кейсы и результаты их прогонов.

Зачем это нужно на практике

Представьте команду из шести человек: три разработчика, тестировщик, аналитик и менеджер. Тестировщик нашёл двадцать дефектов за релиз. Если рассказывать о них голосом на созвоне или писать в общий чат, произойдёт следующее: половина забудется, вторая половина будет починена дважды, а на вопрос «а что вообще осталось до релиза?» никто не ответит.

Баг-трекер решает три задачи, которые чат не решает никогда:

Ничего не теряется. Задача не исчезает из системы, пока кто-то явно её не закроет с указанием причины.
Видно состояние. В любой момент можно ответить: сколько открытых багов, сколько из них блокирующих, что уже починено и ждёт проверки.
Есть история. Через полгода можно открыть задачу и увидеть, кто, когда и почему решил, что «это не баг, а фича».

Самый популярный инструмент на рынке — Jira от Atlassian. Есть и другие: YouTrack, Redmine, Azure DevOps, GitLab Issues, Kaiten. Логика везде похожа, поэтому разберём её на примере Jira — научившись ей, вы за день освоите любой другой трекер.

Жизненный цикл бага: workflow

Workflow — это набор статусов задачи и разрешённых переходов между ними. По сути это конечный автомат: задача всегда находится ровно в одном статусе, и из каждого статуса можно уйти только в те, которые разрешил администратор проекта.

Типовой путь бага выглядит так:

Open  -->  In Progress  -->  Ready for QA  -->  Closed
  ^                              |
  |                              v
  +--------  Reopened  <-----  (баг не починен)

А вот что означает каждый статус и, главное, кто в этот момент отвечает за задачу — это и есть ключ к пониманию трекера.

Статус	Чей мяч	Что это значит
`Open` / `To Do`	Лид, менеджер	Баг заведён и ждёт, когда его возьмут в работу
`In Progress`	Разработчик	Кто-то чинит прямо сейчас
`In Review` / `Code Review`	Другой разработчик	Правка написана, её смотрят коллеги
`Ready for QA` / `Resolved`	Тестировщик	Исправление выкачено на тестовый стенд, нужна перепроверка
`Reopened`	Разработчик	Тестировщик проверил и баг воспроизводится снова
`Closed` / `Done`	Никто	Вопрос закрыт, задача в архиве

Самая важная строка здесь — Ready for QA. Это единственный статус, в котором мяч на стороне тестировщика, и именно он должен быть вашим рабочим списком каждое утро. Всё остальное — фон.

Резолюция: отказ — тоже результат

Закрытие бага не всегда означает «починили». В Jira рядом со статусом есть отдельное поле Resolution (резолюция) — причина закрытия. Не путайте их: статус говорит «где задача», резолюция — «чем всё кончилось».

Резолюция	Когда ставится	Что делать тестировщику
`Fixed`	Дефект устранён	Перепроверить и закрыть либо переоткрыть
`Duplicate`	Такой баг уже заведён	Проверить, что это правда тот же дефект, а не похожий
`Cannot Reproduce`	У разработчика не воспроизводится	Добавить окружение, версию, видео, логи — почти всегда виноват неполный баг-репорт
`Won't Fix`	Осознанно решили не чинить	Убедиться, что решение принял тот, кто имеет право (product owner), и оно записано в задаче
`Not a Bug` / `Works as Designed`	Так и задумано	Уточнить требования: если поведение «задумано», но неочевидно, это может быть баг документации или UX

Cannot Reproduce — личное оскорбление для тестировщика и одновременно сигнал: в вашем баг-репорте не хватило данных. Версия сборки, браузер, тестовые данные, шаги — половина таких возвратов лечится одним аккуратным описанием.

Из чего состоит задача-баг

Карточка бага в Jira — это не «поле для текста», а набор структурированных данных. Минимальный набор, который ждёт от вас любая команда:

Summary:      Корзина: при количестве 0 итоговая сумма становится отрицательной
Project:      SHOP
Type:         Bug
Priority:     High
Severity:     Major
Affects Ver.: 2.3.1
Environment:  stage, Chrome 126, macOS 14
Assignee:     (не заполнено — возьмёт лид)
Reporter:     a.ivanova

Steps to reproduce:
  1. Открыть /cart с товаром «Кружка» (цена 500 ₽)
  2. В поле количества ввести 0 и нажать Enter

Expected:  товар удаляется из корзины, сумма 0 ₽
Actual:    товар остаётся, в блоке «Итого» показывается -500 ₽

Attachments: cart-negative.png, har-file.har

Отдельно про два поля, которые новички путают чаще всего.

Severity (серьёзность)	Priority (приоритет)
Насколько сильно баг ломает продукт. Техническая характеристика.	Насколько срочно его чинить. Бизнес-решение.
Ставит обычно тестировщик	Ставит менеджер / product owner
Пример: опечатка в юридическом тексте оферты — severity Minor	…но priority Blocker, потому что послезавтра проверка

Связи задач: как из списка получается картина

Отдельные баги — это ещё не управление качеством. Ценность появляется, когда задачи связаны. В Jira для этого есть два механизма.

Иерархия: Epic (большая функциональность) → Story / Task (пользовательская история) → Sub-task (подзадача). Баг обычно живёт на уровне Story: «Баг в оформлении заказа» логично привязать к эпику «Оформление заказа».

Ссылки (Issue links): плоские связи между любыми задачами.

blocks / is blocked by — «этот баг блокирует релизную задачу». Самая полезная связь: она превращает баг из строчки в списке в аргумент.
duplicates / is duplicated by — дубликаты. Всегда закрывайте дубль ссылкой на оригинал, а не просто удаляйте.
relates to — «где-то рядом». Ни к чему не обязывает, но помогает собрать контекст.
is caused by — баг появился после конкретной задачи. Бесценно для регрессий: сразу видно, чей код сломался.

Плюс поля Fix Version (в какой релиз чиним) и Affects Version (где нашли). Именно они позволяют менеджеру за секунду ответить: «что осталось до версии 2.4.0».

Где живут тест-кейсы: TestRail и Zephyr

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

Поэтому появились TMS. Самые известные:

Инструмент	Как связан с Jira	Особенность
TestRail	Отдельный продукт + интеграция	Классика жанра: разделы, кейсы, test runs, отчёты. Живёт своей жизнью рядом с трекером
Zephyr Scale	Плагин внутри Jira	Кейсы — такие же сущности Jira, всё в одном окне, не нужен второй логин
Qase, Allure TestOps	Интеграция	Сильны в связке с автотестами: результаты автопрогонов подтягиваются автоматически
Excel / Google Sheets	Никак	Работает на старте, разваливается на второй сотне кейсов: нет истории прогонов и связи с багами

Ключевое понятие TMS — test run (прогон): вы берёте набор кейсов, привязываете к версии сборки и проходите их, отмечая результат.

`Passed`	Фактический результат совпал с ожидаемым
`Failed`	Не совпал → заводим баг и линкуем его к кейсу
`Blocked`	Проверить невозможно: стенд лежит, другой баг перекрывает путь
`Retest`	Нужно перепроверить (например, после фикса)
`Skipped` / `N/A`	Не входит в область этого прогона

Разница между Failed и Blocked кажется формальной, но именно она даёт честный отчёт: «60 passed, 5 failed, 35 blocked» означает «мы вообще не проверили треть», а не «всё почти хорошо».

Как это работает

Под капотом Jira workflow — это конечный автомат, описанный администратором проекта. У каждого перехода могут быть:

Conditions — кто вправе выполнить переход (например, закрыть баг может только reporter или QA-роль);
Validators — что должно быть заполнено (нельзя перевести в Closed без Resolution);
Post-functions — что произойдёт автоматически (назначить задачу обратно на reporter, поставить дату, отправить письмо).

Поэтому если кнопки нужного перехода нет — это не «Jira сломалась», а «у вашей роли нет прав на этот переход» или «не заполнено обязательное поле». Ответ почти всегда там.

Второй механизм, который экономит часы, — JQL (Jira Query Language), язык поиска задач. Три запроса, которые стоит сохранить в закладки в первый же день:

# Что мне нужно перепроверить прямо сейчас
project = SHOP AND status = "Ready for QA" AND fixVersion = "2.4.0" ORDER BY priority DESC

# Мои открытые баги, которые никто не трогает больше недели
project = SHOP AND reporter = currentUser() AND status = Open AND updated <= -7d

# Всё, что блокирует релиз
project = SHOP AND priority in (Blocker, Critical) AND resolution = Unresolved

Сохранённый JQL-фильтр, выведенный на дашборд, — это ваш «пульт» на релизе. Он же — ответ на утренний вопрос менеджера «ну как мы там?».

Частые ошибки

Заголовок «Не работает корзина». Такой баг нельзя найти поиском, нельзя приоритизировать и нельзя понять без открытия. Формула хорошего summary: где + что происходит + при каких условиях.
Пять багов в одной задаче. Один дефект — одна задача. Иначе задача не сможет быть закрыта: четыре пункта починили, пятый нет, и она вечно висит в Reopened.
Утонуть в статусах. Не пытайтесь держать в голове весь борд. Работайте по одному фильтру: «мои задачи в Ready for QA». Всё, что не в нём, — не ваша забота в эту минуту.
Закрывать баг «по слову разработчика». Пока вы сами не воспроизвели старые шаги на новой сборке — баг не проверен. «Я починил» — это Ready for QA, а не Closed.
Спорить о Priority. Приоритет — решение бизнеса. Ваша работа — честно поставить Severity и приложить факты (сколько пользователей задето, есть ли обходной путь). Дальше решает product owner.
Тест-кейсы в личном Excel. Кейсы, о которых знаете только вы, не существуют для команды: их не переиспользуют, по ним нет истории и на них нельзя сослаться из бага.
Failed без заведённого бага. Красный кейс в прогоне, за которым не стоит задача в трекере, — это забытый дефект. Правило: Failed → баг → ссылка.

Итоги

Баг-трекер хранит дефекты, TMS — тест-кейсы и прогоны. Связывает их ссылка «кейс упал → вот баг».
Workflow — это конечный автомат: важен не столько статус, сколько на чьей стороне сейчас мяч. Ваш статус — Ready for QA.
Resolution объясняет, чем закончилась задача. Cannot Reproduce — почти всегда следствие неполного баг-репорта.
Severity ставит тестировщик (насколько сломано), Priority — бизнес (насколько срочно).
Связи blocks, is caused by, duplicates и поля версий превращают список задач в управляемую картину релиза.
Не утонуть в статусах помогает один сохранённый JQL-фильтр вместо чтения всего борда.