1. Jira как инструмент тест-
менеджмента
February 21, 2013 www.ExigenServices.com
1 www.ExigenServices.com
2. СОДЕРЖАНИЕ
Краткий обзор Jira в контексте тестирования
Зачем использовать Jira как инструмент тест-менеджмента
Иерархия задач в Jira
Добавление Feature Groups
Добавление тестов в Jira
Регрешн – оценка скоупа и времени
Стандартные тест-практики в Джира
Определение тестового покрытия
Сбор тестовых метрик
2 www.ExigenServices.com
3. КРАТКИЙ ОБЗОР JIRA В КОНТЕКСТЕ
ТЕСТИРОВАНИЯ
Что такое Jira
Что такое Компонент
Что такое “issue” (сущность)
Иерархия задач в Jira
Взаимосвязь элементов Jira
Как добавлять задачи в Jira
На примере проекта ETPONE
3 www.ExigenServices.com
4. ЧТО ТАКОЕ JIRA
Вся проектная информация хранится в базе данных
Jira – тул, который позволяет нам работать с этой информацией
Jira поддерживает типизацию данных
Jira настраивается под нужды проекта
DATABASE JIRA
4 www.ExigenServices.com
5. ЧТО ТАКОЕ КОМПОНЕНТ
Стул Медведя
cтол
шкаф
Мишуткин стульчик
скамеечка
Стул Медведицы
5 www.ExigenServices.com
6. ЧТО ТАКОЕ “ISSUE”
“Issue” это проектная сущность в Jira
Issue бывают разных типов, например:
– Bug
– User story
– Sub-task
– Test case
– Или любой другой, который вам нужен
* Джиру можно настраивать под нужды проекта
Не все типы issues равны
6 www.ExigenServices.com
7. ИЕРАРХИЯ ЗАДАЧ В JIRA
Jira поддерживает всего 2 уровня иерархии
Более гибкие зависимости – с помощью линок
7 www.ExigenServices.com
9. КАК ДОБАВЛЯТЬ ЗАДАЧИ В JIRA
Для того, чтобы добавить любой тип issue:
– Выбрать этот тип из меню
– Наполнить содержанием
– Слинковать с другими задачами
9 www.ExigenServices.com
10. ЗАЧЕМ ИСПОЛЬЗОВАТЬ JIRA ДЛЯ ТЕСТ-
МЕНЕДЖМЕНТА
Вся проектная информация хранится в одном месте
– Доступна всей команде
– Не нужно создавать отдельных аккаунтов
– Проще отслеживать покрытие требований кейсами
– Удобно для DMT (Development manual testing)
– Проще поддерживать тесты
10 www.ExigenServices.com
11. ДОБАВЛЕНИЕ ТЕСТОВ В JIRA
Добавление типа “feature group”
Добавление тест-кейса
Линкование тестов
Создание тестовых сценариев
11 www.ExigenServices.com
12. ДОБАВЛЕНИЕ FEATURE GROUP
Что такое Feature Group?
Зачем нужен Feature Group?
Пример Feature Group
Жизненный цикл Feature Group
12 www.ExigenServices.com
13. ЧТО ТАКОЕ FEATURE GROUP
Feature group это контейнер тестовых задач
Устойчивость
User Interface Юзабильность Безопасность
и прочность
13 www.ExigenServices.com
14. ЗАЧЕМ НУЖЕН FEATURE GROUP
Feature group нужен для:
– структурирования тест кейсов
– нахождения “affected functionality”
– создания планов регрешн тестинга
14 www.ExigenServices.com
16. ЖИЗНЕННЫЙ ЦИКЛ FEATURE GROUP
У Feature group eсть всего 2 статуса:
– Открытый (используется)
– Закрытый (если данная группа стала неактуальна)
Мы не можем удалять Feature Groups
Mы можем настраивать фильтры, чтобы видеть только
актуальные данные
16 www.ExigenServices.com
17. ДОБАВЛЕНИЕ ТЕСТ КЕЙСА
Как добавлять тест-кейсы
Стандартные поля тест-кейса
Другие полезные параметры кейса
Состояния тест-кейса
С чем линкуются тест-кейсы
Как линкуются тест-кейсы
17 www.ExigenServices.com
18. КАК ДОБАВЛЯТЬ ТЕСТ-КЕЙСЫ
Тест-кейсы добавляются как подзадачи Feature Groups
a) More actions->
b) Create sub-task ->
c) Выбрать тип Test-Case sub-task
Кейсу можно менять родителя
a) More actions ->
b) Move ->
c) Change parent
d) Select new Parent
18 www.ExigenServices.com
19. СТАНДАРТНЫЕ ПОЛЯ ТЕСТ-КЕЙСА
Summary – имя тест-кейса
Preconditions – входные условия
Entry point
Actions – шаги теста
Expected result – ожидаемый результат
Priority – Приоритет (от блокера до trivial)
19 www.ExigenServices.com
20. ДРУГИЕ ПОЛЕЗНЫЕ ПОЛЯ
Parameters
– Автоматизирован
– Зависит от браузера
– Зависит от локали
Components
К какому/каким из компонентов кейс относится
Original estimate
Примерное время на прохождение теста.
Зависит от Parameters
20 www.ExigenServices.com
21. СОСТОЯНИЯ ТЕСТ-КЕЙСА
Open
Reopen
Passed
Failed
Blocked
Deprecated
21 www.ExigenServices.com
22. С ЧЕМ ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ
Тест кейсы линкуются с:
User stories
– Для оценки тестового покрытия
– Для создания тест-планов
Саб-таскам, как
– DMT (developer manual testing)
– Test execution (в качестве тест-плана)
Багам
– Для удобства восприятия
– Для создания дополнительного тест-кейса
– Для более детального повторного прохождения
22 www.ExigenServices.com
23. КАК ЛИНКУЮТСЯ ТЕСТ-КЕЙСЫ
Чтобы залинковать кейс:
а) More Actions ->
b) Link ->
c) Выбрать тип связи (executes) ->
d) Выбрать один или несколько Issues
23 www.ExigenServices.com
24. СТАНДАРТНЫЕ ТЕСТ-ПРАКТИКИ В JIRA
Создание тест плана
Определение тестового покрытия
Практика ДМТ
Поддержка тест-кейсов
Оценка скоупа регрешена
Оценка времни для регрешн тестинга
Сбор тестовых метрик
24 www.ExigenServices.com
25. СОЗДАНИЕ ПЛАНА ТЕСТИРОВАНИЯ
Для юзер-стори:
– Открываем юзер стори
– Читаем и анализируем требования
– Открываем подзадачу Test-execution
– Перечисляем всё, что нужно протестировать
– Заходим в Feature Groups
– Линкуем уже существующие тесты к нашей стори
– Создаем тесты, которых еще нет
– Линкуем
В итоге, получаем список линок на тесты.
Это и будет планом тестирования.
.
25 www.ExigenServices.com
26. ОПРЕДЕЛЕНИЕ ТЕСТОВОГО ПОКРЫТИЯ
Каждаю юзер стори имеет список требований
Каждая тестовая подзадача тоже =>
Залинковав тесты к
а) Подзадаче
б) Основной юзер-стори
мы гарантируем полное тестовое покрытие.
Список тестов доступен всей команде и заказчику.
26 www.ExigenServices.com
27. ПРАКТИКА DMT
DMT = Developer Manual Testing
Уменьшает количество багов
Дает общее видение функциональности
– Тестеры дают список тестов
– Девелоперы проходят тесты сами
Такска DMT асайнится на разработчика
27 www.ExigenServices.com
28. ПОДДЕРЖКА ТЕСТ КЕЙСОВ
При изменении требований, находим affected кейсы в Feature
группах
Так как базовые кейсы являются entry points, достаточно
одного изменения
История изменения кейса доступна
При регрешн-тестировании – перепроверка актуальности
28 www.ExigenServices.com
29. ОЦЕНКА СКОУПА РЕГРЕШН ТЕСТИНГА
Открыть Featrue groups
Выбрать тесты высшего приоритета по текущей
функциональности
С помощью филтров, выбрать все аксептенс тесты
Слинковать с задачей регрешн
29 www.ExigenServices.com
30. ОЦЕНКА ВРЕМЕНИ НА РЕГРЕШН
Определить глубину тестирования
– Проверить параметры тест-кейса
– Выделить самые важные параметры
Время на прохождение*к-во параметров
Суммировать время всех тестов
При необходимости:
– Уменьшить количество параметров
– Сделать выборку самых важных тестов
30 www.ExigenServices.com
31. СБОР ТЕСТОВЫХ МЕТРИК
Как собирать тестовые метрики:
Настроить и расшарить фильтры для
– Acceptance кейсов
– Автоматизированных кейсов
– Общего количества кейсов
– Пройденных за неделю
– Упавших за неделю и т.д
i.e: project = ESR AND component in (Rejta, EMPTY) AND issuetype
= "Test Case sub-task" AND status !=Deprecated AND priority =
Blocker
31 www.ExigenServices.com
Editor's Notes
Этот тренинг предназначен для тестировщиков, Разработчиков, Менеджеров проектов, Конфигурейшн менеджеров и всех, кому интересно, как пользоваться джирой для хранения тест-кейсов. Цель этого тренинга, показать, как можно добавлять, структурировать и использовать тесты в джире, Собирать тестовые метрики наряду с проектными и определять качество продукта с помощью обычных фильтров.
В этой презентации я расскажу: Что такое Jira в контектсе тестирования Зачем использовать для хранения тест-кейсов джиру Как создавать, хранить и поддерживать тест-кейсы Как структурировать кейсы в джире Как создавать тест план Как выбрать тесты и оценить время на регрессионное тестирование О жизненном цикле теста Об использовании стандартных тест – практик в Jira Об отслеживании покрытия требований тест кейсами О сборе тестовых метрик Проект, как и любой из наших в Джире, состоит из набора юзер сторей и соответствующих подзадач. Я специально создала проект, не имеющий никакого отношения к IT сфере, чтобы не отвлекать внимание на технические моменты. https://jira.exigenservices.com/browse/ETPONE (все стори в фильтре all stories)
Любая баг-трекинговая система – удобный интерфейс к базе данных ошибок. За исключением того, что работает не только с багами, но и всей проектной информацией, как требования, чейнд-реквесты, компоненты и даже тест кейсы. Основное преимущество джиры в том, что она позволяет структурировать проет, раздробив его на модули, а модули в свою очередь на более мелкие единицы – юзер стори. Данные в джира могут быть разных типов. В зависимости от типа данных, нам доступны с этими данными разные действия.
Как я уже сказала, Jira позволяет дробить проект на логические компоненты. Например, задача нашего проекта – сделать кухонную мебель для 3х медведей из сказки. Сначала мы перечисляем все основные предметы мебели, которые должны сделать. Это и будет компонентами, или модулями нашего проекта. https://jira.exigenservices.com/browse/ETPONE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel
Чтобы реализовать компонент, нужно выполнить множество задач. Задачи в Jira o дним словом называются issue. Issue могут быть разных типов – Юзер стори, бага, саб-таска и так далее. Основная разница между ними в том, что одни из них являются конкретной задачей минимального размера, которую может выполнить один человек, а другие, контейнерами для этих мелких выполнимых задач. Вот пример основных « user stories » проекта: https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25613 Например, мы у нас есть issue типа юзер стори – построить стул-качалку для Мишутки https://jira.exigenservices.com/browse/ETPONE-3 Это задача-контейнер, которая дробится на более мелкие подзадачи (или же, мелкие задачи наследуются от задачи-контейнера). Пока все задачи не выполнены, основная тоже не считается выполненной. И есть «недробимые» типы – подзадачи, как забить гвоздь или, например, покрыть стул лаком. Создать подзадачу для подзадачи невозможно.
Как я уже говорила выше, есть задачи контейнеры, от которых наследуются подзадачи Любой набор данных должен быть структурирован Для структурирования данных в джира используются всего 2 уровня иерархии Более гибкой структуры можно добиться с помощью использования линок ( issue любого типа могут линковаться с issue любого типа)
Ключевым для проекта является сущность «Компонент» (или модуль) Все сущности джира связаны между собой А) отношением родитель-ребенок Б) линками. Поэтому вероятность «потерять» какой-либо нужный кусок практически равна нулю.
https://jira.exigenservices.com/browse/ETPONE Как я уже говорила, мы можем «настраивать» свой проект и определять, какой набор задач нам нужен. В некоторых проектах нужны чейндж реквесты, риски и так далее.
M ы можем хранить всю проектную информацию в одном месте Информация доступна всей команде Ta ким образом, не нужно создавать отдельные аккаунты для отдельного тест-тула, вся команда, включая разработчиков, может видить все кейсы через джиру. Проще отслеживать покрытие требований тест кейсами. Это очень полезно, когда на проекте используется практика ДМТ – Development manual testing. Легче обновлять тесты по мере изменения требований Обо всем этом речь пойдет дальше Проще собирать метрики по продукту, так как вся необходимая информация хранится в одном месте и собирается на уровне фильтров. Например, мы легко можем узнать, сколько тестов было пройдено за неделю, сколько из них упало, сколько было автоматизировано, и сколько устарело. Проще оценивать время на прохождения регрешн-тестинга.
Добавляем тип задачи « Feature group » Добавляет сам тест кейс, как сабтаску к feature group Линкуем тест-кейсы (саб-таски) к сторям Линкуем feature group к сторям Используем стандартный воркфлоу в Джире (или кастомизируем его)
Мы обсудим: что такое Feature group , и зачем он нужен И какой у него жизненный цикл Второй - куда писать кейсы и как их структурировать.
На слайде 5 мы говорили о том, что такое Компонент (логическая единица или модули, на которые мы делим наш проект) https://jira.exigenservices.com/browse/ETPONE#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel Feature Group делает примерно то же самое, но для тестов https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25614 Как мы видим, у компонентов проекта можно выделить общие модули для тестирования. К каждому из тестовых модулей ( Feature Group) мы добавляем соответствующие тест-кейсы.
Нам нужно структурировать наши тесты, но в Jira есть всего два уровня: Основная задача и подзадача. Для того, чтобы иметь структуру тестов в джире, мы создаем «условную единицу» – Feature group ( в данном случае, мы выделили основные общие параметры, по которым мы будем тестировать каждый из компонентов). https://jira.exigenservices.com/secure/IssueNavigator.jspa?mode=hide&requestId=25615 Единственное, что нам нужно от Feature group – это возможность давать ему название и создавать тест-кейсы в виде саб-тасок (об этом позже).
https://jira.exigenservices.com/browse/ETPONE-72 В нашем проекте есть определенные явно-указанные требования к надежности (разные, для каждого из компонентов) А также неявно указанные требования – как защита от термитов и рассыхание мебели. Если требования на надежность разные для каждого из компонентов, мы добавляем отдельные тесты. Если есть тест, который одновременно относится к каждому из компонентов (как защита от термитов и рассыхания), нет нужды клонировать его. Достаточно слинковать его с соответствующей юзер-стори. Если требования на прочность поменялись, нам не нужно искать стори, к которой были привязаны тесты. Мы заходим в нашу Feature группу и модифицируем то, что есть. Если нас просят построить еще один предмет мебели, мы проходимся по Feature группам, реюзаем что есть, добавляем чего нет и полностью уверены, что ничего не забыли.
У Feature Group есть всего 2 состояния: Открытый и Закрытый. Открытый – значит, что данная функциональность сейчас актуальна. Закрытый – что функциональность больше не используется. Мы не можем удалять компоненты, зато имеем возможность их переоткрывать, вместе с тест кейсами.
Тест-кейсы добавляются как подзадачи к Feature Groups https://jira.exigenservices.com/browse/ETPONE-73 Если есть сомнения, к какой из Feature групп добавлять кейс – ничего страшного. Кейсу всегда можно поменять родителя. https://jira.exigenservices.com/browse/ETPONE-78
Стандартные поля тест кейса: Summary – собственно, название тест кейса 2) Preconditions – Например, если мы хотим проверить качество краски, предусловием для нас является то, что стол готов, покрашен и высох (указывать в качестве прекондишена, что какой-либо кейс уже пройден – не очень хороший тон, так как тест, на который мы сслыаемся, может быть изменен) 3) Entry point – например, мы находимся на определенной странице нашего приложения. Entry point можно делать ссылкой на тест. Если приходит новый тестер и не знает, как добраться до какой-либо страницы, он пройдет по ссылке и всё сразу поймет. Приоритет – Blocker, Critical, Major, Minor, Trivial Если мы указвыаем тесту приоритет блокер, мы, тем самым, говорим, что это один из аксептенс тестов. Есть смысл проходить все кейсы с таким приоритетом перед каждым релизом.
Parameters – параметры – набор чек боксов – A втоматизирован, Завист от браузера (может вести себя по разному в разынх браузерах), Зависит от локали – т.е отображение в разных локалях (языках) приложения может быть разным Компонент - принадлежность теста к какому-либо компоненту Грубая оценка времени на прохождение теста. В случае, если проставлена галочка browser dependent оценка умножается на количество браузеров. Если тест зависит от локали – на количество локалей
1) Изначально, при создании, тест кейс находится в состоянии О pen. При прохождении кейса ему дается статус passed, failed Если кейс открыт, значит, он не проходился Если кейс переоткрыт, значит, его снова надо пройти. Переоткрытие удобно при составлении тест плана. Например, у нас есть 2 дня на регрессионное тестирование и список тестов. https://jira.exigenservices.com/browse/ETPONE-99 Рядом с каждым тестом есть значок, который указывает текущее состояние. Например: Упал, пройден, не проходился. Чтобы не забыть, что мы уже смотрели, а что нет (особенно если на проекте больше 1 тестера), перед началом тестирования все кейсы переводятся в состояние реопен. Если у кейса состояние НЕ опен, значит, его уже проходили в этой задаче. История тест кейса (и его статусов) хранится во вкладке Activity – History 2) Если тест кейс уже не актуален, удалять его мы не можем, но можем переводить в состояние Deprecated (устаревший) И использовать фильтры, чтобы они не показывали тесты такого типа. Если удаленный кусок функциональности приложения был восстановлен, мы восстанавливаем и все deprecated тесты.
Итак, тест кейсы имеет смысл линковать с Юзер сторями – чтобы понять, какой набор тестов нужно пройти для полного тестирования функциональности С саб-тасками, например – DMT. DMT – это development manual testing – набор самых приоритетных тестов, которые проходит девелопер, прежде чем отдать задачу на тестирование. Или с саб-таской test execution. Бывает, что юзер стори декомпозируется на разные под-задачи, которые выполняют разные разработчики. https://jira.exigenservices.com/browse/ETPONE-66 Тогда тестер проводит тестирование этих задач по отдельности. Открывая задачу test execution , тестер сразу видит, какой набор тестов ему нужно пройти. Если в функциональности были найдены баги даже после DMT , список линок на кейсы помогает оценить, что именно не было учтено при написании тест кейсов. Еще, конечно, имеет смысл линковать тест с багами. На это есть как минимум 2 причины: Если мы проходим кейс повторно, то сразу видим, куда еще можно покопать, чтобы убедиться в полной надежности. Если соответствующего багу кейса не нашлось (а баг важный), то нужно такой кейс написать. Многие задают вопрос, почему бы не добавлять тест-кейс как саб-таску к юзер-стори. Изначально так и делалось. Но тут есть несколько существенных недостатков. Тест кейсы не структурированы. Нужно много времени, чтобы найти, например, все тесты, относящиеся к определенному компоненту системы. По этой же причине, при обновлении части функциональности, сложно найти и отредактировать все релевантные тесты Поскольку тесты раскиданы по сторям, сложнее делать выборку для регрессионного тестирования. Так как каждый из кейсов прогоняется не единожды, тест-кейсы не имеют состояния closed. В результате мы получаем кучу закрытых сторей в released versions , в которых есть открытые таски. Что усложняет отслеживание состояния проекта.
https://jira.exigenservices.com/browse/ETPONE-79 Для того, чтобы залинковать тест-кейс, нужно открыть сам кейс, выбрать из меню More Actions опцию Link, выбрать тип связи – executes и ввести номер таски, с которой Вы тест кейс линкуете. При открытии таски, к которой прилинкован тест, Вы увидите issue links – где будет список всех кейсов, которые нужно пройти и их статус. https://jira.exigenservices.com/browse/ETPONE-96
https://jira.exigenservices.com/browse/ETPONE-3 Показать на практике Все тесты в джире unassigned. Имеет смысл ассайнить только саб-таску ( execution), в которой находится тест-план.
Как показано в примере выше, мы перечислили то, что нужно протестировать и залинковали соответствующие тесты. Таким образом, гарантировали полное покрытие . Заинтересованные стороны могут посмотреть на список и оценить, стоит ли что-либо добавить или убрать.
ДМТ сводится к тому, что тестеры выделяют основные тест-кейсы по куску функциональности каждого разработчика. Прежде чем передать кусок на тестирование, девелопер проходит основные кейсы сам. Создается задача DMT и туда линкуется список основных тестов, которые девелопер проходит сам на тестовом инвайренменте. Тесты не ассайнятся на девелопера, на девелопера ассайнится DMT c абтаска. Если при дмт найдены баги, разработчик, не отвлекаясь на другие задачи, фиксит их и передает задачу на финальное тестирование.
https://jira.exigenservices.com/browse/ETPONE-66 Поскольку кейсы привязаны не к стори, а к компоненту, при изменении требований можно легко найти и изменить тесты. Важно, что мы всегда можем видеть историю изменений кейса. Легче обновлять тесты по мере изменения требований
Как оценить, какие тесты нам нужно пройти для регрессионного тестирования: Каждый кусок функциональности относится к определенной feature группе. Для выборки кейсов мы открываем соответствующий компонент (тест-компонент) и выбираем оттуда характерные тесты. Если текущая разработка может повлиять на другие компоненты, мы открываем список кейсов для этих компонентов и тоже делаем выборку Есть набор тестов с приоритетом Blocker. Это тесты вроде acceptance, которые нужно проходить перед самым релизом, чтобы убедиться что вся система в основном работает Проще оценивать время на прохождения регрешн-тестинга. к каждому из кейсов можно добавить предварительную оценку времени на прохождение. Мы выбираем набор тестов, складываем это время, и получаем время на регрессионное тестирование. С помощью стандартных фильтров легко планировать скоуп и время на регрешн – потом расскажу как (Проще выявлять скоуп регрешена. При прохождении теста фиксируется дата изменения результата (модификации теста). С помощью фильтров в джире можно найти тесты нужного приоритета (или относящиеся к нужному куску функциональности), которые не проходились с (нужной даты). И внести их в список регрешн таски (залинковать). Выбранные кейсы линкуются к таске “regression”. Эту таску можно отправить на апрувал разработчикам, или, в случае неожиданных косяков, документально подтвердить, что всё было протетстировано
При регрешене или беглом аксептенс-тестинге не всегда обязательно проходить тест во всех браузерах и локалях Поэтому выбираем достаточный минимум параметров, умножаем original estimate ( время на один прогон) на количество параметров и получаем итоговую цифру. Например, один прогон в одном браузере на одной локали занимает 4 мин. Если мы проверяем 3 браузера = 12 минут на прохождение теста. Если проверяем 3 локали в каждом браузере = 36 минут на прохождение теста.
Как собирать тестовые метрики в джире? Тестовые метрики собираются с помощью фильтров. Например, еженедельно нам нужно: Сколько у нас открытых кастомерских багов Сколько открытых тестерских багов Сколько всего тест кейсов, сколько автоматизировано, сколько пройдено за неделю и т д. Для этого мы пишем фильтр. Например: Выбрать все тест кейсы из проекта, статус которых поменялся меньше недели назад. И получаем к-во пройденных тест кейсов. Фильтр сохраняется. И если он правильно написан, будет акруален всегда.