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

При этом инструмент предлагает «единый вид всех элементов бэклога – будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест-кейсов, задач на тестирование и найденных дефектов. 

Я инженер функционального тестирования в компании «ЛАНИТ Экспертиза». В этой статье в блоге ЛАНИТ я расскажу, как использовать функционал Jira в задачах тестирования: от сохранения запросов до интеграции с другими системами.

Статья будет полезна для всех участников QA-команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться. 

Работа с фильтрами, JQL и массовыми операциями

Оптимизировать работу QA-команд в Jira можно с помощью фильтров, Jira Query Language (JQL) и массовых операций. Фильтры и JQL позволяют тестировщикам быстрее находить необходимую информацию, создавать динамические отчеты и анализировать те данные, которые нужны. JQL поможет создать гибкие запросы: сохранил один раз — и под рукой нужная выборка. Это экономит время и нервы, особенно, когда задач становится все больше. Массовые операции помогают, когда нужно разом поменять статус или назначить ответственного сразу для десятков задач. 

А если использовать эти инструменты вместе, то работа становится проще и быстрее, а отчёты — понятнее. Но обо всем по порядку.

Фильтр в Jira – это сохраненный поисковый запрос. В расширенном поиске (Advanced search) можно использовать язык JQL (Jira Query Language) для гибкого отбора задач. Расширенный поиск –  мощный способ найти нужные задачи: с помощью JQL можно задать критерии, недоступные в базовом режиме (например, сортировку через ORDER BY).

JQL предназначен для всех: разработчиков, тестировщиков, менеджеров и других пользователей. В JQL запрос состоит из полей (status, priority, assignee и т.д.), операторов (=, !=, IN, AND, OR, >= и др.) и значений. Например:

project = «TEST» AND status = «In Progress»

Ниже – примеры типовых запросов, которые часто используют QA-команды (предполагается, что проект тестов имеет код TEST, а тип задач – Task).

По статусу:

project = TEST AND issuetype = Task AND status = «In Progress»: 

• найдет все задачи типа Task в проекте TEST, находящиеся в статусе «In Progress». Аналогично можно использовать любое другое значение поля status, например «Done» или «Testing».

По исполнителю:

project = TEST AND issuetype = Task AND assignee = currentUser() 

• покажет задачи, назначенные на текущего пользователя (помогает смотреть свои задачи). Можно указать конкретного пользователя: assignee = IvanPetrov.

По приоритету:

project = TEST AND issuetype = Task AND priority = Highest 

•  отфильтрует только задачи с высоким приоритетом. Например, комбинация priority = High AND status = Open покажет все открытые задачи высокой приоритетности.

По дате создания/обновления

• Недавно созданные:
  project = TEST AND issuetype = Task AND created >= -7d ORDER BY created DESC 

Покажет задачи, созданные за последние 7 дней, отсортированные по дате создания.

• С момента последнего изменения:
  project = TEST AND issuetype = Task AND status CHANGED AFTER -1w 

Выберет задачи, у которых за последнюю неделю менялся статус (можно отслеживать недавние изменения). Похожий эффект даст

updated >= -7d (задачи, обновленные за последнюю неделю).

По группам или ролям:
project = TEST AND assignee IN membersOf(»qa-team») 

•  Все задачи проекта TEST, назначенные на участников группы QA (функция membersOf).

  

Любой запрос выполняется после нажатия Search (Поиск). Результат – список задач, соответствующих критериям. Этот список можно сохранить как фильтр, чтобы быстро повторять поиск в будущем.

Использование оператора NOT IN

Для сокращения написания запроса JQL удобно использовать оператор NOT IN. К примеру, нам необходимо отфильтровать все задачи, которые в данный момент в работе. В запрос мы должны включить все возможные статусы за исключением статусов «Закрыто» и «Тестирование завершено». 

Стандартный запрос будет выглядеть так:

project = TEST AND status in (Разработка, «В работе», Возвращено, ПРИОСТАНОВЛЕНО, Тестирование, Стабилизация, Верификация, Новая, Аналитика, «Готово к тестированию», «Подготовка материалов»)

А с оператором NOT IN запрос выглядит компактнее:

project = TEST AND status not in (Закрыто, «Тестирование завершено»)

Обратите внимание, что значения из нескольких слов обрамляются кавычками. Оператор NOT IN не будет соответствовать полям, не имеющим значения (т.е. пустым полям). Чтобы включить задачи, где поле status пустое (если это применимо к вашему процессу), вам потребуется добавить условие OR status is EMPTY.

Сравнение запросов

Стандартный запрос (длинный, с status in)

project = TEST AND status in (Разработка, «В работе», Возвращено, ПРИОСТАНОВЛЕНО, Тестирование, Стабилизация, Верификация, Новая, Аналитика, «Готово к тестированию», «Подготовка материалов»)

Компактный запрос (с status not in)

project = TEST AND status not in (Закрыто, «Тестирование завершено»)

Использование скобок () в запросах

Очень часто необходимо отфильтровать данные со сложными условиями отбора, например, все задачи со статусом «В работе», у которых высокий приоритет ИЛИ дата создания после 9 июня 2025 года. Можно отдельно сформировать два запроса, но это будет не удобно для визуализации и есть большая вероятность, что одна задача попадет в оба фильтра. Намного рациональнее объединить запросы и сложные условия отбора заключить в скобки с использованием логических операторов.

Скобки () имеют наивысший приоритет в JQL, что означает, что любые выражения, заключенные в них, вычисляются в первую очередь. Оператор AND имеет более сильное связывание, чем OR, поэтому без скобок условия могут быть интерпретированы не так, как задумано.

Пример запроса со скобками:

project = TEST AND status = «В работе» AND (priority = High OR created >= 2025-06-09)

В этом примере сначала будет вычислено условие в скобках (priority = High OR created >= 2025-06-09), а затем результат этого условия будет объединен с остальными через оператор AND.

Сохранение и управление фильтрами

После выполнения нужного запроса нажмите кнопку «Сохранить как» (Save as) над строкой поиска. В появившемся окне укажите понятное название и описание фильтра. Желательно в названии отметить проект и тип поиска (например, «TEST: Открытые задачи»).

После сохранения фильтр можно найти на странице Фильтры → Все фильтры (Filters → View all filters). Здесь в списке видны все личные фильтры и те, которыми с вами поделились. Для поиска своего фильтра введите часть названия в поле поиска (1). Выберите название фильтра, чтобы открыть его (2). Здесь вы можете изменить критерии поиска фильтра, добавить или изменить существующие публикации, а также управлять подписками. Посмотрите, кто является владельцем, зрителями и редакторами фильтра (3). Популярность (4): посмотрите, сколько человек поставили лайк под фильтром. Управление подписками, копирование фильтра, редактирование фильтра, изменение владельца фильтра или удаление фильтра (5).

Открыв фильтр, вы можете следующее.

• Изменить критерии: нажмите «Edit» или «Изменить запрос», чтобы поправить JQL.

• Настроить доступ: через «Детали» (Details) задайте, с кем поделиться фильтром. Выберите группы или конкретных пользователей, которым разрешено его просматривать.

• Отметить как избранный: кликните на звездочку рядом с названием фильтра – тогда он появится в меню «Избранное» для быстрого доступа.

• Создать подписку: для автоматической рассылки результатов фильтра нажмите «Детали» → «Новая подписка» (New subscription). Укажите получателей (себя или группу), частоту (каждый день, неделю или по cron) и подтвердите «Subscribe». Тогда Jira будет отправлять на почту список задач, подходящих под этот фильтр, через заданные интервалы. Это удобно, чтобы регулярно получать отчеты без ручного запуска.

Экспорт отфильтрованных данных

Иногда для составления отчетов необходимо перенести отобранные фильтрацией данные в текстовые редакторы или в электронные таблицы. В Jira есть функция «Экспорт», в ней можно выбрать необходимый формат исходного файла. Например, можно выбрать опцию «Экспорт CSV (все поля)» или «Экспорт CSV (текущие поля)».

Если, к примеру, выбрать экспорт «Excel CSV (текущие поля)», то при открытии файла электронной таблицы Вы заметите, что все данные отображаются в одном столбце. Для перевода в привычный табличный вид можно воспользоваться функцией Excel «Текст по столбцам» с разделителем «запятая».

Добавление фильтра на дашборд

Сохраненные фильтры можно выводить на доску (дашборд) с помощью гаджетов. Откройте нужный дашборд или создайте новый. Нажмите Add gadget (нажмите «Добавить гаджет»). В появившемся списке найдите гаджет Filter Results и добавьте его. Этот гаджет отображает результаты выбранного вами фильтра. В настройках гаджета укажите ваш сохраненный фильтр и выберите колонки, которые необходимо показывать. Таким образом, на дашборде всегда будут видны свежие данные по данному запросу (например, все открытые таски проекта TEST).

Массовые операции

Если нужно одновременно изменить сразу много задач, используйте Bulk Change (массовые операции). Учтите важные условия: у вас должны быть глобальные права Make bulk changes и соответствующие права на проект. Также можно обработать не более 1000 задач за раз.

Шаги для массовых операций ниже.

1. Выполните JQL-запрос или выберите нужный сохраненный фильтр – получите список задач.

2. В списке задач нажмите «•••» (меню More) и выберите Bulk Change all X issues.
   

   

3. Отметьте галочками задачи, к которым хотите применить операцию, и нажмите Next.
   

   

После этого откроется мастер массовых изменений. Основные варианты действий следующие.

• Сменить статус (Transition). Выберите опцию Transition work items и нажмите Next. На следующем шаге выберите целевое действие (например, закрыть задачу или перевести в определенный статус) и снова нажмите Next. Если переход требует обязательных полей (обычно это поле «Решение» при закрытии), укажите их и нажмите Next. На последнем шаге проверьте выбранные задачи и переход и нажмите Confirm. Все помеченные задачи изменят статус.

• Изменить поля и назначение. Выберите Edit work items и нажмите Next. Появится список полей, которые можно массово изменить. Поставьте галочку напротив Assignee (Исполнитель) и выберите нужного пользователя – так вы перебросите все выбранные задачи на него. Аналогично можно отметить другие поля: приоритет, метки, версии и т.д. После выбора полей и указания новых значений нажмите Next, просмотрите итог операций и Confirm.

• Удаление. Если требуется, можно выбрать Delete work items – тогда задачи будут удалены. Будьте осторожны, операция необратима.

При выполнении массового изменения у вас будет опция «Send email for this update»: по умолчанию Jira оповестит всех подписчиков задач и участников проектов об изменении. Чтобы этого избежать, снимите галочку перед подтверждением. Это поможет избежать «засыпания» почты ненужными уведомлениями.

Таким образом, с помощью фильтров и JQL можно гибко отбирать задачи по любым критериям (по статусу, исполнителю, приоритету, дате и т.д.), сохранять эти выборки для быстрой повторной работы и даже автоматически получать результаты по почте. А массовые операции помогают управлять сразу группой задач: менять статусы, исполнителей и другие поля за несколько кликов. Используйте эти инструменты, чтобы ускорить и упростить рабочие процессы вашей QA-команды в Jira.

Иерархия задач в Jira: эпики, задачи и подзадачи

Jira Software по умолчанию использует трехуровневую структуру задач: Epic (эпик, уровень 1) → Story/Task (история/задача, уровень 0) → Sub-task (подзадача, уровень -1). 

Эпик – это крупная группа работы (например, тест-кампания), объединяющая множество связанных задач (например, тест-кейсов). 

Задача/история – единичный элемент работы (например, один тест-кейс), который при необходимости можно привязать к эпику. Подзадача – часть работы внутри задачи (например, конкретные шаги тест-кейса). 

Для тестовых проектов часто используют такое соответствие: эпик = тест-кампания, задача = тест-кейс, подзадача = шаги тест-кейса.

Пример: вид Timeline (дорожной карты) в Jira Software с созданным эпиком Epic 1. На таймлайне можно планировать эпики (большие проекты) и просматривать сроки их выполнения. В приведённом примере создаётся новый эпик с коротким названием и описанием, который будет объединять связанные задачи (истории) в рамках этого эпика.

• Создание эпика. Эпик можно создать из вида Timeline/Roadmap или из бэклога Scrum-доски. В Timeline нажмите кнопку «+» в колонке эпиков и введите название и описание эпика. В Scrum-бэклоге откройте панель «Epics» и нажмите Create Epic. Новый эпик появится в списке и будет виден на Timeline и в бэклоге.

• Создание задачи (Story/Task). Стандартную задачу создают кнопкой Create. При создании в company-managed проекте можно сразу указать поле Epic Link или аналог (в team-managed — выбрать эпик через поле Epic в форме), чтобы связать задачу с нужным эпиком. Либо после создания задачи можно перетащить её в эпик на панели эпиков.

• Создание подзадачи (Sub-task): Откройте родительскую задачу и нажмите кнопку «+ Create sub-task» (или пункт Create sub-task) под заголовком задачи. Введите название подзадачи – она автоматически свяжется с текущей задачей как родителем. Подзадача наследует из родителя проект, спринт, уровень безопасности и другие настройки.

Эти связи отображаются на досках и в деталях задач: у каждой задачи видно, к какому эпику она привязана (Epic Link), а подзадачи видны внутри родительской задачи. Например, на странице эпика отображается таблица «Issues in Epic» со связанными задачами (stories/bugs).

Отображение на досках и Timeline

Пример: Kanban-доска в Jira Software (team-managed проект) с колонками «To Do», «In Progress» и «Done». Каждая карточка – это отдельная задача, а цветной ярлык указывает связанный эпик. Колонки доски обычно соответствуют статусам рабочего процесса (workflow) – например: To Do, In Progress, Done.

• Колонки и статусы. Администраторы Jira нередко настраивают колонки доски так, чтобы они соответствовали шагам процесса (статусам). Если у простого процесса три стадии, то можно сопоставить каждой колонке по одному статусу. Для сложных процессов одна колонка может включать несколько статусов – это позволяет упростить внешний вид доски.

• Scrum Backlog. В Scrum-проектах в бэклоге есть панель Epics. Она показывает список всех эпиков проекта – оттуда можно создавать новые эпики и связывать с ними задачи, перетаскивая их в эпик. На спринт-доске задачи разделены по спринтам, а панели «Epics» там нет (но доска все равно фильтрует задачи по их эпикам).

• Подзадачи на доске. По умолчанию подзадачи вложены в родительскую задачу и в бэклоге отображаются под ней. В Scrum-доске можно раскрыть задачу, чтобы увидеть её подзадачи, либо настроить отображение подзадач как отдельных карточек (в настройках доски). На Kanban-доске подзадачи по умолчанию показываются как отдельные карточки внутри тех же статусов, что и родитель.

Таким образом, эпик виден как единая единица работы (цветная метка или панель на Timeline), обычные задачи – как карточки на досках и в бэклоге, а подзадачи – либо внутри своих родителей, либо как отдельные карточки в тех же статусах.

Воркфлоу в Jira: статусы и переходы

Воркфлоу (workflow) в Jira – это последовательность статусов и переходов, по которой проходит задача (issue) от создания до завершения.

Статус – это текущая стадия работы (например, Open, In Progress, Testing, Done), показывающая, на каком этапе находится задача. 

Переход (transition) – это действие, переводящее задачу из одного статуса в другой (например, «Start Progress» переводит из To Do в In Progress). Если задачи необходимо возвращаться назад (например, из Done в In Progress), для этого  создают дополнительный обратный переход.

Пример: простой workflow может выглядеть как To Do → In Progress → Done. Для каждого такого перехода в настройках задаются возможные действия (переходы) и отображаемые кнопки.

Каждый проект в Jira использует один или несколько рабочих процессов. В company-managed проектах набор привязанных workflow описывается схемой рабочего процесса (workflow scheme) – это соответствие между типами задач (эпик, история, задача, подзадача и т.д.) и конкретными workflow. В team-managed проектах весь workflow настраивается внутри самого проекта через визуальный редактор.

На досках Kanban/Scrum состояние задачи видно по тому, в какой колонке она находится: эта колонка соответствует одному или нескольким статусам из workflow. Например, все статусы «In Progress» могут сгруппированы в одну колонку «In Progress» доски. При перемещении карточки по колонкам Jira автоматически выполняет соответствующий переход между статусами (например, при перетаскивании в «Done» вызывается переход в статус Done).

В QA-проектах часто расширяют стандартный workflow, добавляя статусы вроде Testing, Verified, Rejected и др., чтобы отслеживать, на каком этапе находится тестирование. Важно, чтобы у каждого рабочего процесса были чётко определены стартовый статус (например, Open) и один или несколько финальных (например, Done или Closed), а также переходы между ними, отражающие реальный бизнес-процесс тестирования.

В QA-проектах часто расширяют стандартный workflow, добавляя статусы вроде Testing, Verified, Rejected и др., чтобы отслеживать, на каком этапе находится тестирование. Важно, чтобы у каждого рабочего процесса были чётко определены стартовый статус (например, Open) и один или несколько финальных (например, Done или Closed), а также переходы между ними, отражающие реальный бизнес-процесс тестирования.

Настройка воркфлоу: схемы и визуальный редактор

В company-managed проектах администратор Jira создает или изменяет workflow через глобальные настройки: Jira settings → Issues → Workflows. Там можно создавать схемы рабочих процессов и назначать их на проекты. В team-managed проектах (бывшие next-gen) workflow настраивается в самом проекте: Project settings → Issue types → выбрать тип (Epic/Task и т.д.) и нажать Edit workflow.

Новый визуальный Workflow Editor объединяет все инструменты редактирования в одном окне. Панель инструментов позволяет добавлять статусы, переходы и правила (conditions/validators/post-functions) для создания процесса. Графическая диаграмма показывает статусы (блоки) и переходы (стрелки) – можно перетаскивать блоки, чтобы изменить расположение.

• Добавление статусов и переходов. В редакторе нажмите кнопку Add status или Add transition (обычно расположены в тулбаре). Новому статусу можно задать название, цвет и категорию (To Do/In Progress/Done). После добавления статуса нужно соединить его переходом с другими статусами (установить путь движения задач). Например, можно создать статусы «In Review» или «Testing» и соединить их с «In Progress» и «Done».

• Условия (Conditions). Для каждого перехода можно задать условия, ограничивающие возможность его выполнения. Например, условие может проверять, что переход может сделать только пользователь из определённой роли (Developer, Tester и т.д.) или только когда заполнено какое-то поле. Если условие не выполнено, кнопку перехода не увидят пользователи, не соответствующие ему.

• Валидаторы (Validators). Валидатор проверяет введенные пользователем данные перед выполнением перехода (например, обязательно ли заполнено поле «Resolution»). Если проверка не пройдена, переход не выполнится, и пользователь увидит сообщение об ошибке.

• Пост-функции (Post-functions). Это автоматические действия, которые выполняются после успешного перехода. Например, можно настроить, чтобы после перехода в Done Jira автоматически назначала задачу на создателя, добавляла комментарий или меняла значение поля. Среди типовых пост-функций – «Assign to current user» (назначить на того, кто совершил переход), «Update Issue Field» (обновить поле), «Generate change history» и другие. Эти функции выполняются после изменения статуса и записи истории изменения.
  

  

После внесения изменений в рабочий процесс (если он активный), Jira создаёт черновик workflow. Чтобы изменения вступили в силу, необходимо опубликовать его (Update Workflow). При этом Jira может попросить переназначить некоторые задачи, если их статусы не согласуются с новым процессом. Обратите внимание, что для редактирования workflow нужны права администратора (в team-managed – разработчика проекта, в company-managed – права Jira System Administrator).

Подытожим: в Jira Software вы строите иерархию задач (эпик → задача → подзадача) и задаёте для них workflow. С помощью схем и визуального редактора можно настроить под процесс тестирования любые статусы и переходы, а условия и пост-функции позволяют автоматизировать логику движений задач по этапам. Это гибко отображается на досках и в планировщике Timeline, облегчая работу QA-команды с тестовыми кампаниями, тест-кейсами и шагами.

Создание досок, работа с плагинами (включая Structure)

Для визуального планирования тестов в Jira используются доски. В Jira Software доска отображает задачи из одного или нескольких проектов. Существует два основных типа досок: 

• Scrum-доска (с бэклогом и спринтами) – для команд, планирующих работу итерациями, 

• Kanban-доска (с непрерывным потоком) – для команд, сосредоточенных на ограничении незавершённой работы. 

QA-команды могут создавать отдельные доски под свою работу. Например, Scrum-доска QA может содержать спринт с тест-кейсами, а Kanban-доска – процессы быстрого реагирования на баги. Доски настраиваются в меню Boards → Create board или через контекст в проекте (дополнительный «+» возле названия проекта).

Jira изначально разрабатывалась как инструмент для отслеживания задач и управления проектами, а не как специализированная платформа для тест-менеджмента. Это приводит к нескольким ключевым ограничениям, с которыми сталкиваются QA-команды при использовании нативной Jira:

Организация тест-кейсов: в Jira нет удобной иерархической структуры для хранения тест-сьютов и тест-кейсов. Из-за этого они часто разбросаны по разным местам, могут дублироваться, и поддерживать единый порядок становится сложно. В итоге команда тратит больше времени на поиск нужных тестов, а новичкам сложнее разобраться, что где лежит.

Гибкость тестирования. Jira не слишком дружелюбна к разным подходам к тестированию — например, к исследовательскому тестированию, BDD или TDD. Нет и простых способов работать с параметризованными или data-driven тестами. Из-за этого приходится изобретать сложные схемы с дополнительными полями и настройками, и Jira быстро превращается в «монстра» с кучей лишних деталей.

Выполнение и отслеживание тестов. Статусы тест-кейсов тестировщикам приходится менять вручную, что долго и легко запутаться. Нет удобного способа быстро узнать, как идут дела с тестированием в целом, посмотреть метрики или историю запусков — всё это усложняет контроль над процессом.

Автоматизация. Jira не умеет напрямую дружить с популярными инструментами автоматизации (Selenium, Cypress, JUnit) и CI/CD-системами. Поэтому результаты автотестов приходится переносить вручную, и рабочий процесс получается разорванным.

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

Отслеживание дефектов

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

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

Например, популярный плагин Structure for Jira: он даёт возможность наглядно выстраивать задачи в виде дерева, удобно ими управлять и группировать как нужно. Это решает проблему, что в самой Jira такой иерархии «из коробки» нет.

Confluence, как вики-платформа для совместной работы, является незаменимым инструментом для создания, организации и управления документацией в общем пространстве. Она служит централизованным хранилищем для внутренней базы знаний, технической документации, руководств пользователя, политик и процедур. Confluence обеспечивает структурированную организацию контента, эффективный контроль версий, а также возможности комментирования и совместного редактирования в реальном времени, что критически важно для поддержания актуальности и точности документации. Использование шаблонов и макросов (таблицы, информационные панели и разделы) помогает поддерживать согласованность и масштабируемость документации, делая ее легко читаемой и понятной.

Confluence помогает:

• навести порядок в документах: всегда понятно, где что лежит;

• следить за изменениями: вы видите, кто и когда вносил правки;

• работать вместе в реальном времени: несколько человек могут одновременно редактировать документ, оставлять комментарии и быть уверенными, что информация всегда актуальна и точна;

• делать документы единообразными и легко читаемыми: благодаря готовым шаблонам и «умным» элементам (например, таблицам или панелям) ваши документы всегда выглядят профессионально и понятно.

Как связаны Jira и Confluence?

Jira и Confluence отлично дружат между собой. Они могут обмениваться информацией напрямую, благодаря следующим возможностям

1. Встроенной интеграции Atlassian. Это позволяет легко вставлять ссылки на задачи Jira прямо в документы Confluence или выводить списки задач с помощью специальных макросов.

2. REST API. Если вам нужна более сложная автоматизация, вы можете настроить программную связь, чтобы страницы Confluence автоматически привязывались к задачам Jira.

Как это работает на практике

Чтобы они познакомились, нужно создать так называемые «Application Links» (ссылки приложений) в настройках Jira и Confluence. Это как дать им «доверенность» на общение.

Пример. На вашей странице Confluence, где вы описываете план тестирования, вы можете вставить специальный макрос Jira Issues. Этот макрос автоматически покажет все открытые задачи, связанные с этим планом, прямо из Jira. А если вы создадите ссылку на страницу Confluence в задаче Jira (вручную или автоматически), то в карточке задачи всегда будет ссылка на соответствующий документ. Это значит, что актуальная информация из Jira всегда видна прямо в вашей документации.

Интеграция Jira и TestIT

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

Как настроить интеграцию?

Зависит от того, где у вас установлена Jira.

• Для Jira Server: нужно установить специальный плагин Test IT for Jira.

• Для Jira Cloud: интеграция настраивается прямо в TestIT через API-токен Jira (специальный код для доступа).

Что нужно подготовить в Jira?

1. Плагин: установите плагин Test IT for Jira, если у вас Jira Server.

2. API-токен: сгенерируйте API-токен, если у вас Jira Cloud.

Что настроить в TestIT?

Зайдите в TestIT под учётной записью администратора, выберите «Интеграции» и добавьте новую, указав Jira. Введите данные вашей Jira (адрес, логин/пароль или токен) и TestIT проверит соединение.

Какой информацией обмениваются?

Эта интеграция связывает тесты из TestIT с задачами в Jira.

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

• Создание дефектов. Если тест в TestIT провалился, вы увидите кнопку «Сохранить и создать дефект». Нажав её, вы откроете окно создания бага в Jira, где уже будет заполнена вся необходимая информация о проваленном тесте (шаги, ссылки на тест и его результат).

• Обратная связь. После создания дефекта в Jira, в TestIT автоматически появится ссылка на этот баг прямо в результатах теста.

• Копирование тест-кейсов. TestIT может создать копию вашего тест-кейса в Jira как задачу типа TestCase. В этой задаче будут видны все шаги теста, а также его последний результат.

Пример сценария

Представьте, тестировщик запускает тест-план в TestIT и видит, что один тест «Провален». Он нажимает кнопку «Сохранить и создать дефект», выбирает проект в Jira, и в новом баге уже есть вся информация о тесте. Как только баг создан в Jira, в TestIT появляется ссылка на него. Точно так же, если TestIT скопировал тест-кейс в Jira, разработчик сразу видит все шаги и последний результат прохождения каждого шага. Это делает обмен информацией между TestIT и Jira очень эффективным и автоматизированным.

Интеграция Jira и Allure TestOps

Allure TestOps — это платформа для анализа результатов тестирования и управления качеством. Интеграция с Jira помогает связать ваши тесты и автоматические проверки с задачами разработчиков.

Как настроить интеграцию?

Для этого используется плагин Allure TestOps for Jira, который доступен на Atlassian Marketplace. Настройка происходит как в Jira, так и в Allure TestOps с использованием API-токена.

Что нужно сделать?

1. В Jira. Установите плагин Allure TestOps for Jira через «Explore apps» и затем перейдите к его настройкам.

2. В Allure TestOps. Войдите как администратор, перейдите в «Интеграции» и добавьте новую, выбрав Jira. Укажите адрес вашей Jira, создайте API-токен в Jira (в настройках профиля) и вставьте его в Allure TestOps. Также настройте «Issue Mapping», чтобы Allure понимал, каким проектам Jira соответствуют ваши тесты.

3. В плагине Jira. В настройках плагина Allure TestOps for JIRA укажите адрес вашего Allure TestOps и «Integration ID» (идентификатор интеграции из Allure TestOps). Убедитесь, что плагин активен.

Какой информацией обмениваются?

После настройки вы получите двустороннюю связь:

• В Allure TestOps. Просматривая запуски тестов, их результаты или дефекты, вы увидите кликабельные ссылки на связанные задачи Jira.

• В Jira. В карточке задачи Jira появится новая вкладка Allure TestOps. Там будет отображаться список всех запусков и результатов тестов из Allure TestOps, которые связаны с этой задачей. Важно: для этого блок Allure в Jira использует iframe, поэтому у пользователя должен быть доступ к Allure TestOps.

Кроме того, они синхронизируют статусы! Если вы закроете задачу (баг) в Jira, Allure TestOps получит это уведомление и автоматически закроет соответствующий дефект у себя.

Практические сценарии

• Связь автотестов с задачами. Тестировщик может добавить в код автотеста специальную метку с ключом задачи Jira (например, allure.label(»jira», «PROJ-123»)). Когда отчёт загружается в Allure TestOps, эта метка превращается в прямую ссылку на задачу PROJ-123.

• Видимость тестов в Jira. Разработчик, открыв задачу в Jira, сразу видит блок Allure TestOps. В нём отображаются все запуски и результаты тестов, которые имеют отношение к этой задаче (например, сколько раз и какие тесты покрывали этот функционал, и какие из них упали).

• Автоматическое закрытие дефектов. Если разработчик исправил баг и закрыл его в Jira, Allure TestOps автоматически обновит статус соответствующего дефекта на «Закрыт».

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

Автоматизация в Jira: QA-примеры, которые упрощают жизнь

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

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

Всё строится на трёх основных элементах.

1. Триггеры: «Спусковые крючки» для автоматизации

Триггер — это событие, которое запускает ваше правило автоматизации. Это как спусковой крючок, который «говорит» Jira: «Пора действовать!».

Примеры триггеров.

• Создание или изменение задачи: например, когда кто-то создаёт новую задачу или обновляет уже существующую.

• Изменение статуса: когда задача переходит из одного статуса в другой (например, из «В работе» в «Выполнено»).

• Изменение поля: если меняется значение определённого поля в задаче (например, приоритет или ответственный).

• Связывание задач: когда одну задачу связывают с другой.

• По расписанию: правило срабатывает в определённое время (например, раз в день или раз в неделю).

• Входящий вебхук: это когда внешняя система (например, система непрерывной интеграции CI) посылает сигнал в Jira, запуская правило.

2. Условия: «Фильтры» для точной работы

Условие — это «фильтр», который определяет, должна ли автоматизация сработать. Оно проверяет, соответствуют ли задачи определённым критериям, прежде чем выполнить действие. Это помогает избежать ненужных или ошибочных автоматических операций.

Примеры условий

• Если тип задачи — Баг

• Если приоритет бага — Высокий

• Если в названии задачи есть слово auto-test-fail

• Если задача принадлежит конкретному проекту или компоненту

3. Действия: что именно делает автоматизация

Действие — это то, что Jira делает после того, как сработал триггер и были выполнены все условия. Это сама «работа» правила.

Примеры действий

• Создать новую задачу: автоматически создать баг, задачу или любую другую сущность в нужном проекте.

• Изменить текущую задачу: обновить значения полей, например, изменить приоритет или назначить ответственного.

• Добавить комментарий: оставить комментарий в задаче, используя информацию из других полей.

• Изменить статус задачи: перевести задачу в другой статус.

• Отправить уведомление: послать письмо или сообщение в Slack/Microsoft Teams определённым людям или каналам.

• Связать задачи: автоматически связать две или более задач между собой.

• Отправить веб-запрос: послать информацию во внешнюю систему (например, в систему мониторинга).

Многие действия могут использовать «умные значения» (smart values), которые позволяют вставлять информацию из задачи (например, её номер, описание или имя ответственного) прямо в автоматическое сообщение или в поля новой задачи.

Примеры правил автоматизации для QA-команды

Теперь давайте посмотрим, как всё это можно использовать на практике в тестировании:

1. Уведомление о проваленных автотестах

• Триггер: входящий вебхук от вашей системы CI/CD (например, Jenkins, GitLab CI) или изменение поля «Результат теста» на «Провален».

• Условие: задача является «Выполнением теста» (Test Execution) или имеет метку autotest.

• Действие: отправка уведомления в Slack или по электронной почте команде тестировщиков. В сообщении можно автоматически указать ключ задачи и её краткое описание, чтобы сразу перейти к проблемному тесту.

2. Автоматическое создание бага при падении теста

• Триггер: задача типа «Прогон теста» (Test Run) перешла в статус «Провален».

• Условие: у задачи есть метка auto-defect.

• Действие: создать новую задачу типа «Баг» в вашем QA-проекте. Заголовок бага автоматически берётся из названия проваленного теста, а в описании сразу добавляется ссылка на этот тест. Это значит, что каждый упавший автотест мгновенно превращается в баг в Jira!

3. Автоматическое обновление тест-кейса после исправления бага

• Триггер: баг перешёл в статус «Закрыт».

• Условие: этот баг связан с какой-либо задачей-тестом (например, через ссылку или специальное поле).

• Действие: изменить связанный тест-кейс: установить его статус на «Успешно» или добавить комментарий типа «Исправлено в связи с закрытием бага». Это помогает поддерживать актуальность статусов ваших тест-кейсов без ручного вмешательства.

4. Автоматическое создание страницы релиза в Confluence

• Триггер. Фиксация новой версии продукта (например, версия «выпущена») или добавление метки release к задаче. Важно: Для этого правила рекомендуется добавить условие, чтобы избежать создания лишних страниц. Например, условие может проверять тип задачи (только для задач типа «Релиз»), принадлежность к определенному проекту или наличие специфического значения в поле (например, «Статус релиза» = «Финальный»). Без условия правило будет срабатывать на каждое событие триггера, что может быть нежелательно.

• Действие. Создать новую страницу в Confluence в заданном пространстве, используя шаблон «Заметки о релизе». Заголовок страницы будет автоматически сформирован, например, из названия версии или даты. Вам останется только заполнить содержимое.

5. Оповещение о новом баге с высоким приоритетом

• Триггер. Создание новой задачи типа «Баг» в вашем QA-проекте.

• Условие. Приоритет бага — «Высокий».

• Действие. Отправить электронное письмо или сообщение в Slack ответственному специалисту или лидеру команды.

Таким образом, гибкая система Jira Automation позволяет вам настроить уведомления и действия для всей цепочки тестирования — от обнаружения упавшего автотеста до создания бага и даже обновления документации. Используя эти встроенные возможности, ваша QA-команда может значительно ускорить реакцию на проблемы, автоматизировать учёт дефектов и поддерживать актуальность задач, минимизируя ручную работу. И самое главное — все эти примеры можно реализовать без использования сторонних плагинов, прямо в стандартной Jira Automation.

Заключение

Jira – мощный инструмент для QA при правильной настройке фильтров, досок, связей и интеграций. Ключевые приёмы: JQL-фильтры и быстрые фильтры – для поиска нужных задач, воркфлоу и иерархия задач – для чёткого процесса, доски и плагины (Structure) – для удобного планирования, а также автоматизация и интеграция (Confluence, CI).  

В сочетании с правильной организацией тест-кейсов и чек-листов в самой Jira или Confluence эти методы позволяют полностью перенести тестовую документацию в единое рабочее пространство.

Ссылки, используемые в статье

• https://support.atlassian.com/jira-software-cloud/docs/use-advanced-search-with-jira-query-language-jql/

• https://support.atlassian.com/jira-software-cloud/docs/manage-filters/

• https://support.atlassian.com/jira-software-cloud/docs/save-your-search-as-a-filter/

• https://support.atlassian.com/jira-software-cloud/docs/update-multiple-issues-at-once/

• https://support.atlassian.com/jira-software-cloud/docs/what-are-jira-workflows/

• https://support.atlassian.com/jira-cloud-administration/docs/configure-workflow-schemes/

• https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/

• https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/

• https://support.atlassian.com/confluence-cloud/docs/use-jira-applications-and-confluence-together/

• https://support.atlassian.com/confluence-cloud/docs/insert-jira-issues-and-jira-charts/

• https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/ 

• https://confluence.atlassian.com/jirasoftwareserver0820/working-with-issues-1095249401.html