Рабочие процессы Jira для отслеживания дефектов
Updated Jul 2026
Почему отслеживание дефектов — ключевой навык QA
Jira остаётся доминирующим инструментом для отслеживания дефектов в agile-командах. Качество ваших баг-тикетов напрямую влияет на скорость исправления проблем разработчиками. Расплывчатый, плохо написанный баг-репорт отнимает время разработчика, получает низкий приоритет и может быть никогда не исправлен. Понятный, хорошо документированный баг-репорт с шагами воспроизведения, доказательствами и контекстом исправляется быстро.
Написание понятных тикетов о дефектах
Хороший баг-тикет отвечает на три вопроса: Что произошло? Что должно было произойти? Как воспроизвести?
Шаблон
Title: Checkout fails with 500 error when applying expired coupon code
Priority: High
Severity: Critical
Component: Checkout / Payments
Environment: Staging (v2.4.1), Chrome 120, macOS 14
Sprint: Sprint 23
Steps to Reproduce:
1. Add any item to cart
2. Proceed to checkout
3. Enter expired coupon code "SAVE20-2024"
4. Click "Apply"
Expected: Error message "This coupon has expired" displayed inline
Actual: Page returns HTTP 500, user sees generic error page
Additional Context:
- Valid coupon codes work correctly
- Bug introduced after commit abc123f (coupon validation refactor)
- Server logs show NullPointerException in CouponService.validate()
- Affects all users, not environment-specific
Attachments: screenshot.png, server-error-log.txt, HAR file
Что делает этот тикет эффективным
- Заголовок конкретный: «Checkout fails with 500 error when applying expired coupon» — это поисковый и однозначный текст. Сравните с «checkout broken», который не говорит ничего.
- Шаги пронумерованы и точны: разработчик может воспроизвести менее чем за минуту.
- Ожидаемое vs фактическое ясно: не нужно гадать, что должно происходить.
- Дополнительный контекст сужает расследование: ссылка на коммит и серверный лог экономят часы отладки.
- Вложения доказывают проблему: скриншоты и логи — это доказательства, а не пересказ.
Приоритет vs серьёзность
Это разные измерения. Серьёзность измеряет техническое воздействие. Приоритет измеряет бизнес-срочность. Они часто совпадают, но не всегда.
| Низкая серьёзность | Высокая серьёзность | |
|---|---|---|
| Высокий приоритет | Имя генерального директора написано с ошибкой на странице «О нас» | Обработка платежей ломается для всех пользователей |
| Низкий приоритет | Подсказка смещена на странице настроек администратора | Экспорт данных повреждает записи (функция используется раз в квартал) |
Уровни серьёзности
| Уровень | Определение | Пример |
|---|---|---|
| Критический | Система неработоспособна, потеря данных, нарушение безопасности | Все пользователи не могут войти; номера кредитных карт доступны |
| Серьёзный | Ключевая функция сломана, обходного пути нет | Оформление заказа не работает; невозможно создать заказ |
| Незначительный | Функция работает, но с проблемами, обходной путь есть | Результаты поиска отображаются некорректно, но пользователи могут фильтровать вручную |
| Тривиальный | Косметика, опечатка, мелкая проблема UI | Кнопка смещена на 2px; опечатка в подвале |
Уровни приоритета
| Уровень | Определение | Время реакции |
|---|---|---|
| Критический | Исправить немедленно, все силы на решение | Часы |
| Высокий | Исправить в этом спринте | Дни |
| Средний | Исправить в следующем спринте | 1-2 спринта |
| Низкий | Исправить при возможности | Бэклог |
Жизненный цикл дефекта
Чётко определённый жизненный цикл дефекта обеспечивает отслеживание багов от обнаружения до решения.
New → Open → In Progress → Fixed → In Verification → Closed
↓ ↓
Deferred Reopened → In Progress
↓
Won't Fix / Duplicate
Описание статусов
| Статус | Кто отвечает | Что происходит |
|---|---|---|
| New | QA (создатель) | Баг зафиксирован со всей необходимой информацией |
| Open | Тимлид / Триаж | Баг рассмотрен, приоритизирован и назначен |
| In Progress | Разработчик | Разработчик активно работает над исправлением |
| Fixed | Разработчик → QA | Исправление закоммичено, PR слит. Передаётся QA на верификацию |
| In Verification | QA | QA верифицирует исправление в целевом окружении |
| Closed | QA | Исправление успешно верифицировано |
| Reopened | QA → Разработчик | Исправление не решило проблему или внесло новую |
| Deferred | Тимлид | Не будет исправлено в этом релизе; перенесено на будущий спринт |
| Won't Fix | Тимлид + PO | Принято как есть; не стоит усилий на исправление |
| Duplicate | QA / Тимлид | Такой же баг уже зафиксирован; ссылка на оригинал |
Триаж дефектов
Триаж — это процесс рассмотрения новых багов и принятия решений по ним. Эффективный триаж предотвращает ситуацию, когда баг-репорты лежат без внимания неделями.
Чеклист триажа
- Воспроизводим ли он? Если нет, запросите у автора больше деталей или попробуйте воспроизвести сами.
- Это дубликат? Поищите в существующих багах перед созданием нового.
- Какова серьёзность? Оцените техническое воздействие.
- Каков приоритет? Учтите бизнес-влияние, затронутых пользователей, обходные пути.
- Кто должен исправить? Назначьте правильную команду или разработчика.
- Когда исправлять? В этом спринте, в следующем или в бэклог?
Ежедневная встреча триажа (15 минут)
Многие команды проводят быструю ежедневную встречу триажа для обработки новых багов:
- Рассмотрение всех багов, созданных за последние 24 часа
- Подтверждение приоритета и серьёзности
- Назначение ответственных
- Привязка к связанным историям или эпикам
Антипаттерны баг-репортов
| Антипаттерн | Проблема | Решение |
|---|---|---|
| «Оно не работает» | Нет действенной информации | Требуйте шаги воспроизведения, ожидаемое vs фактическое |
| Отсутствует информация об окружении | Невозможно воспроизвести | Всегда указывайте браузер, ОС, версию приложения, окружение |
| Нет вложений | Разработчик не может увидеть то, что видели вы | Всегда прикрепляйте скриншоты, логи, HAR-файлы |
| Дублирующие баги | Тратится время разработчика | Ищите перед созданием; связывайте дубликаты |
| Завышенный приоритет | Всё «критическое», поэтому ничего не критическое | Резервируйте «Критический» для сценариев падения системы |
| Баг-репорт в Slack | Теряется в переписке, не отслеживается | Фиксируйте в Jira; ссылку можно оставить в Slack |
| Нет шагов воспроизведения | Разработчик тратит часы, пытаясь воспроизвести | Нумеруйте каждый шаг явно |
Связывание дефектов с контекстом
Хорошие тикеты дефектов связаны, а не изолированы.
Bug: SHOP-789 (Checkout 500 on expired coupon)
├── Caused by: SHOP-654 (Coupon validation refactor)
├── Blocks: SHOP-800 (Coupon testing story)
├── Related to: SHOP-567 (Coupon expiry epic)
└── Fix PR: github.com/org/repo/pull/123
Эти связи создают сеть контекста, помогающую всем видеть полную картину.
Практическое упражнение
- Напишите баг-репорт для реальной проблемы, которую вы обнаружили, используя шаблон выше
- Проверьте 5 существующих баг-репортов в вашем проекте. Достаточно ли в них шагов воспроизведения? Вложений? Правильная ли серьёзность?
- Настройте ежедневный процесс триажа для вашей команды (даже неформальный)
- Создайте шаблон баг-тикета Jira с обязательными полями
- Найдите баг «Won't Fix» в вашем бэклоге и проверьте, актуально ли решение
- Потренируйтесь связывать баги с историями, эпиками и PR для полной трассируемости