Перевод статьи «Optimizing QA with JIRA: A Step-by-Step Guide».
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 14.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
JIRA широко используется в QA для отслеживания и управления процессами тестирования ПО. Вот как это обычно происходит:
- Отслеживание багов: QA-команды используют JIRA для отслеживания и управления багами, обнаруженными в процессе тестирования. Они могут вносить детальные описания, шаги для воспроизведения, прикреплять скриншоты и назначать приоритеты, чтобы обеспечить оперативное устранение проблем.
- Управление тест-кейсами: JIRA помогает систематизировать и управлять тест-кейсами. QA-инженеры могут создавать тест-планы, оформлять тест-кейсы, привязывать их к требованиям или пользовательским историям, и отслеживать статус их выполнения (например, Pass/Fail/Blocked).
- Управление воркфлоу: JIRA предоставляет настраиваемые воркфлоу, которые отражают процесс QA — от планирования тестов и их выполнения до исправления багов. Это помогает поддерживать четкость и согласованность тестовых процессов в команде.
- Интеграция с разработкой: JIRA упрощает взаимодействие между QA и разработчиками. Тестировщики могут привязывать баги к конкретным изменениям кода или пользовательским историям, что помогает разработчикам быстрее разбираться в проблемах и исправлять их.
- Отчетность и метрики: JIRA предлагает встроенные инструменты отчетности, которые позволяют QA-менеджерам отслеживать ход тестирования, тенденции дефектов и другие метрики, важные для оценки качества ПО.
В этой статье представлено пошаговое руководство по наиболее важным функциям JIRA и ее месту в цикле разработки.
Предлагаем пройти Тест на знание основ JIRA
Создайте аккаунт и свой первый проект
Первое, что вам нужно сделать — создать учетную запись в Atlassian. После создания учетной записи выберите JIRA.
Затем создайте новый проект и выберите Scrum.
Большинство компаний используют Scrum. Это Agile-методика гибкого управления проектами, которая помогает командам сорганизовать и спланировать свою работу в среде Scrum.
Затем вам будет предложено два типа проекта. Я буду использовать Company-Managed (Проекты компании), так как этот вариант предоставляет больше возможностей, что позволит нам рассмотреть все детали.
Теперь ваш проект должен выглядеть следующим образом:
В верхней части интерфейса расположены вкладки. Для просмотра или создания нового проекта перейдите во вкладку Projects (Проекты) и выберите View All Projects (Просмотреть все проекты).
Я создам новый проект в качестве примера и назову его «Credit Card Banking».
В рамках этого проекта я планирую разработать следующие функциональные модули:
- Модуль авторизации (Login Module)
- Панель управления кредитными картами (Credit Card Dashboard)
- Профиль пользователя (Profile)
Что такое Epic и Story?
В Agile-методологии функциональный модуль называется “Epic” (Эпик). Это высокоуровневое требование, которое необходимо реализовать. В нашем примере проекта предстоит выполнить три эпика.
Затем у нас есть User Stories (Пользовательские истории) — это наименьшая единица работы в рамках Agile. Эпик — это крупная задача, которая разбивается на набор пользовательских историй. Цель пользовательской истории — разъяснить, как именно функциональная возможность принесет пользу клиенту.
Например, эпиком будет модуль авторизации, а историями — каждый раздел, необходимый для реализации эпика, такие как поля редактирования, кнопки входа, текст и т. д.
Пользовательские истории состоят из нескольких предложений, описывающих желаемый результат простым языком. Формат пользовательской истории должен быть написан с точки зрения заказчика.
“Как [роль], я хочу [действие], чтобы [цель]”.
“Как пользователь кредитной карты, я хочу вводить свои учетные данные, чтобы войти в аккаунт”.
Создание Эпика
Теперь давайте создадим наш первый эпик. Находясь на вкладке Backlog, нажмите Create (Создать) и в выпадающем списке Issue type (Тип задачи) выберите Epic. Заполните поле Summary (Тема) и Description (Описание) вашего Эпика и нажмите Create (Создать).
Создание пользовательской истории
Теперь создадим пользовательские истории. Снова нажмите Create (Создать), в выпадающем списке Issue type (Тип задачи) выберите Story (История) и укажите Summary (Тема).
Мы можем добавить Labels (Метки): Feasibility (оценка выполнимости) и Organization (организация задач); а также выбрать Priority (Приоритет).
Затем мы можем связать нашу историю с нашим эпиком.
Наконец, нажмите Create (Создать), чтобы создать эту пользовательскую историю.
Затем мы можем просмотреть наш эпик, выбрав выпадающий список Epic и включив Epic для отображения в боковой панели. Ниже, в разделе Backlog, вы увидите связанную пользовательскую историю.
Чтобы просмотреть все задачи, выберите вкладку Issues (Задачи) слева.
Далее нам нужно заполнить поле Description (Описание). Оно должно быть написано с точки зрения клиента.
Затем лид вместе с командой определяет критерии приемки (acceptance criteria).
Например, если необходимо запретить клиенту вводить специальные символы в поле редактирования, система должна выводить ошибку при такой попытке.
Также важно убедиться, что пользовательские истории не содержат слишком много критериев приемки.
Команда проведет “уточнение бэклога” (backlog grooming/refinement), чтобы сократить количество критериев и определить, сколько стори-поинтов (Story Points) будет назначено задаче.
Вам нужно оценить сложность истории, назначив ей числовое значение. Команда проведет совместное «голосование» для определения этого значения, и после достижения консенсуса результат нужно будет внести в поле Story Points.
Можно также использовать поле Сomments (Комментарии) в нижней части раздела пользовательской истории, чтобы отметить одного из членов команды, если это необходимо, и обратиться к нему с конкретным вопросом/проблемой.
Создание подзадачи в истории
Далее нам нужно создать подзадачу в истории (необходимо нажать Create subtask). Это позволит назначить конкретных членов команды на выполнение конкретной задачи в рамках истории. Таким образом, роли будут четко распределены, и можно будет точно определить, когда конкретная задача в истории будет выполнена.
Создание компонента
Теперь представим, что над нашим проектом работает несколько команд, и мы хотим, чтобы разные команды работали над разными компонентами. Выберите вкладку Components (Компоненты) в меню слева.
Примечание: Чтобы продолжить, вам может потребоваться доступ к бесплатной пробной версии.
Как только вы перейдете на страницу Compass выберите Create (Создать) → Component (Компонент).
Затем заполните поле Name (Имя) для компонента. Я назову его “Team 1“. Мы можем создать Owner Team и пригласить в нее всех пользователей этой команды. Затем нажмите Create (Создать).
После этого вы попадете на страницу обзора компонента, где можно добавить его описание (заполнив поле Description) .
Теперь мы можем вернуться на страницу Jira и выбрать вкладку Issues (Задачи) слева. В правой части экрана найдите опцию More Fields (Дополнительные поля), и в раскрывшемся списке выберите опцию Components (Компоненты) . Из списка компонентов выберите “Team 1“, и все!
Создание релиза
Среди дополнительных полей вы также заметите опцию Fix Versions (Версии исправлений).
Для начала поясню, что такое релиз. Когда разработка завершена, продукт необходимо выпустить. Например, вы закончили работу над эпиком “Модуль авторизации” (Login Module) и хотите выпустить его.
Мы можем выбрать вкладку Releases (Релизы) слева и нажать Create Version (Создать версию).
После того как вы нажмете кнопку Save (Сохранить), вы увидите свой релиз на странице.
Далее нам нужно привязать нашу историю к этому релизу. Перейдите на вкладку Issues (Задачи) и выберите созданную ранее историю. Теперь мы можем выбрать Login Release (Релиз Модуля авторизации), который мы создали в опции Fix Versions.
Привязка релиза к истории будет означать, что данная история запланирована к выпуску в продакшн 12 июля 2024 года (указано в поле Release Date (Дата релиза)). Если у вас есть несколько историй с такой же датой выпуска, вы можете привязать их к этой версии Login Release (Релиз Модуля авторизации).
После выполнения привязки мы можем вернуться на вкладку Releases (Релизы), и нам ещё нужно будет добавить задачи в этот раздел Release.
Важно отметить: если вы видите, что версия скоро выйдет, но в разделе статуса все еще указано “To Do“, вам стоит уточнить у своей команды, каков ее фактический статус, и установить значение “Done“, если она завершена, а ответственный проверил, что всё функционирует как требуется.
Что такое спринт?
Допустим, у нас есть 25 пользовательских историй для завершения эпика “Модуль авторизации” (Login Module) с датой релиза через 2,5 месяца. Мы разделим эти истории на разделы, или спринты, чтобы распределить наше время соответствующим образом.
В идеале спринт длится 2 недели. В конечном счете, наш 2-месячный срок будет разделен примерно на 4 спринта. Это означает, что наш эпик будет разбит на дедлайны с двухнедельными интервалами, примерно по 6 историй в каждом.
Спринт 1: 6 историй
Спринт 2: 6 историй
Спринт 3: 6 историй
Спринт 4: 7 историй
Спринт 5: Регрессионное тестирование
В зависимости от компании, вы будете выпускать продукт после каждого рабочего спринта.
Планирование спринта
Теперь мы можем создать наш спринт. В JIRA перейдите на вкладку Backlog и нажмите кнопку Create Sprint (Создать спринт). Ваша команда будет совместно определять, какие задачи можно включить в конкретный спринт. Объём задач зависит от скорости работы вашей команды. Если потребуется удалить спринт, все истории автоматически вернутся в Backlog .
Используя Story Points, мы можем решить, сколько историй мы можем включить в спринт. Также необходимо учитывать уровень приоритета историй, чтобы расставить приоритеты в спринтах и завершить наиболее важные истории для конкретного релиза.
Обычно емкость спринта определяется на основе общей суммы story points. Я создал несколько пользовательских историй и добавил story points для каждой из них. Теперь я перетащу свои истории из Backlog в спринт , учитывая при этом их оценку по story points.
Итак, у нас есть первый спринт, который должен быть завершен в течение 2 недель. Далее нажимаем Start Sprint (Начать спринт) и заполняем его детали и описание.
После создания спринта вы попадете в раздел Active sprints (Активные спринты).
Здесь отображаются задачи, которые:
- Ещё не начаты (To Do)
- В работе (In Progress)
- Уже завершены (Done)
В определенный момент вы проведете «Стендап-встречу» (Stand-Up Meeting), где сможете обсудить планы на день и обновления по пользовательским историям.
Рассмотрим пользовательскую историю, которую мы уточнили нашими подзадачами. Разработка завершена — теперь можно выполнить ручное тестирование и перевести задачу в статус «В работе» (In Progress).
После того, как каждая подзадача будет отмечена как «Done», вам необходимо проконсультироваться с владельцем продукта, чтобы убедиться в соответствии критериям приемки. И только после этого можно присвоить истории статус «Done».
Обычно это обязанность QA — продемонстрировать завершённые задачи владельцу продукта и перевести их в статус «Done».
Вы можете отслеживать все эти обновления в режиме реального времени, обеспечивая тем самым отличный метод контроля Scrum-процесса.
Когда все истории будут завершены, вы нажмете кнопку Complete Sprint (Завершить спринт).
Отчеты об ошибках
Аналогично созданию эпика и истории, мы можем создать задачу с типом Ошибка (Bug).
После создания ошибка будет отображаться в бэклоге вместе с остальными задачами.
Теперь вы понимаете все ключевые аспекты работы с JIRA в Agile Scrum-проектах.