Jira для тестировщика: как вести дефекты и не утонуть

Инструмент сам по себе не делает работу лучше, но плохое ведение задач съедает часы всей команды. Разберём, что действительно важно, а что можно не запоминать.

Что такое Jira и зачем она в процессе

Jira — трекер задач: место, где живут требования, задачи разработки и дефекты, и где видно, кто чем занят. Тестировщику она нужна для трёх вещей: заводить дефекты, следить за их судьбой и понимать, что вообще происходит в спринте.

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

Жизненный цикл дефекта

Стандартный путь и ветки, которые от него отходят:

Статус	Что означает	Чей ход
Open / New	Дефект заведён	Ждёт разбора
In Progress	Взят в работу	Разработчик
Fixed / Resolved	Исправление сделано	Ждёт проверки
Verified / Closed	Проверено, дефекта нет	Тестировщик
Reopened	Не починили или сломали снова	Тестировщик вернул
Rejected	Это не дефект	Нужно обоснование
Duplicate	Уже есть такая задача	Ссылка на оригинал обязательна
Deferred	Отложено осознанно	Решение команды, а не забывчивость

Какие поля заполнять всегда

• Тип задачи — Bug, а не Task: иначе дефект не попадёт в отчёты по качеству.
• Компонент — по нему задачи разлетаются нужным командам без ручной маршрутизации.
• Версия, где найдено — без неё через месяц не понять, актуален ли дефект.
• Окружение — стенд, браузер, устройство, роль пользователя.
• Severity — ваша оценка, с обоснованием в описании (см. разбор severity и priority).
• Вложения — скриншот, видео, HAR, идентификаторы для поиска в логах.

Всё остальное — по правилам конкретной команды. Не стоит на новом месте изобретать свою схему полей: посмотрите два десятка закрытых дефектов и делайте так же.

Связи между задачами

Недооценённая часть, которая экономит время при разборе. Jira умеет связывать задачи, и три типа связей стоит использовать регулярно.

1. Relates to — дефект связан с задачей, при выполнении которой появился. Разработчик сразу видит, куда смотреть.
2. Blocks — дефект мешает проверить другую задачу. Так становится видно, почему тестирование стоит.
3. Duplicate — с обязательной ссылкой на оригинал. Без ссылки статус бесполезен.

JQL: фильтры, которые пригодятся сразу

JQL — язык запросов внутри Jira. Учить целиком не нужно, но три-четыре сохранённых фильтра сильно упрощают день.

• Мои дефекты, ждущие проверки: reporter = currentUser() AND status = Resolved
• Всё критичное в текущем релизе: fixVersion = "2.15.0" AND severity in (Blocker, Critical)
• Заведённое мной за неделю: reporter = currentUser() AND created >= -7d
• Открытое по моему компоненту: component = "Checkout" AND status != Closed ORDER BY priority DESC

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

Пять ошибок ведения задач

1. Обсуждение в мессенджере вместо комментариев. Через месяц никто не вспомнит, почему дефект закрыли. Решения — в задачу.
2. Два дефекта в одной задаче. Починят один, второй уедет в закрытое.
3. Молчаливый Reopened. Вернули без комментария — разработчик тратит время, выясняя, что не так. Напишите, что именно всё ещё воспроизводится.
4. Rejected без обоснования. Работает в обе стороны: и вы должны обосновывать, и от вас вправе требовать.
5. Задачи-призраки. Дефект висит полгода в Open, никто про него не помнит. Раз в спринт стоит просматривать свои старые задачи и честно закрывать неактуальные.

Где хранится всё остальное

Jira — про задачи. Требования, спецификации и договорённости живут в вики (Confluence или аналог), тестовая документация — либо там же, либо в специальной системе. Смешивать не стоит: дефект со встроенным описанием требований невозможно поддерживать.

Практическое правило: в задаче — ссылка на требование, а не его пересказ. Требование поменяется, и пересказ начнёт врать.

Доски и спринты глазами тестировщика

Задачи в Jira живут на доске, и тестировщику важно понимать одну вещь: колонка «Testing» — не склад. Задача, застрявшая там на неделю, блокирует спринт так же, как незаконченная разработка.

Полезные привычки: брать задачи в проверку по мере готовности, а не копить до конца спринта; сразу переводить в нужный статус, чтобы доска отражала реальность; на ежедневной встрече говорить не «тестирую», а что именно проверено и что мешает.

И отдельно — оценка сроков. От тестировщика её ждут наравне с разработчиками, а новички стесняются называть цифру. Ориентир простой: возьмите время на прохождение сценариев и удвойте — вторая половина уйдёт на разбор находок, перепроверки и переключения.