Контекст
Jira — центральная система учёта работы почти в каждой продуктовой команде, и для QA это не просто «место, куда заводят баги». Здесь живёт весь контекст: требования в сторях, история решений в комментариях, связи между дефектами и фичами. Основная единица организации — проект: контейнер с собственным ключом (например, SHOP), набором типов задач, воркфлоу и правами доступа. Ключ проекта становится префиксом каждой задачи: SHOP-1024 читается однозначно в любом чате и коммите. Важно понимать разницу между company-managed проектами (настройки управляются администраторами централизованно, схемы переиспользуются между проектами) и team-managed (команда сама правит свои статусы и поля, но настройки изолированы). От типа проекта зависит, к кому идти с просьбой «добавьте поле Severity» — к админу Jira или к своему тимлиду. QA, который понимает эту механику, тратит минуты там, где новичок теряет дни на переписку.
- Проект = контейнер задач с уникальным ключом, воркфлоу и правами.
- Company-managed: централизованные схемы, меняет администратор Jira.
- Team-managed: команда настраивает проект сама, но настройки не переиспользуются.
Рабочий алгоритм
Когда вы приходите в новый проект, разберите его устройство по шагам — это займёт полчаса и сэкономит недели недопонимания:
- Откройте Project settings → Issue types и выпишите, какие типы используются: Epic (крупная цель на квартал), Story (пользовательская ценность), Task (техническая работа), Bug (дефект), Sub-task (декомпозиция внутри задачи).
- Уточните командные договорённости: куда заводить дефект, найденный до релиза сторя, — отдельным Bug или Sub-task к сторе? В разных командах правила различаются.
- Посмотрите иерархию: Epic → Story/Task/Bug → Sub-task. Sub-task не может существовать без родителя и не появляется на борде отдельной карточкой в большинстве конфигураций.
- Проверьте схему полей для типа Bug: какие поля обязательны при создании (Environment, Affects Version, Priority), чтобы ваши баг-репорты не возвращали на доработку.
Пример из практики
Команда интернет-магазина работает в проекте SHOP. QA-инженер во время тестирования сторя SHOP-450 «Оплата картой» нашёл два дефекта. Первый — кнопка «Оплатить» не задизейблена во время запроса, из-за чего возможна двойная оплата: это прямое нарушение приёмочных критериев сторя, и по договорённости команды он заведён как Sub-task под SHOP-450, чтобы стори не ушёл в Done с открытым дефектом. Второй — в старом флоу «Сохранённые карты» маска карты отображается без последних четырёх цифр: этот дефект не относится к текущему сторю, поэтому заведён отдельным Bug SHOP-472 с заполненным Affects Version = 2.14 и прилинкован к эпику «Платежи». На стендапе тимлид сразу видит: один дефект блокирует стори спринта, второй уйдёт в бэклог триажа. Правильный выбор типа задачи здесь — не бюрократия, а способ управлять приоритетами без лишних слов.
Частые ошибки
Типичные промахи новичков при работе с проектами и типами задач:
- Заводить все дефекты как Task «потому что так быстрее» — баги выпадают из метрик качества, фильтров триажа и отчётов, команда теряет картину дефектов.
- Создавать Sub-task для дефекта из другой функциональности — при закрытии родительского сторя дефект «исчезает» из поля зрения и всплывает в проде.
- Игнорировать разницу company-managed / team-managed — часами искать настройку, которой в вашем типе проекта просто нет, вместо того чтобы написать администратору.
- Не проверять проект перед созданием задачи — баг, заведённый в чужой проект, живёт незамеченным, пока его случайно не найдут.