Test & Test Case Management in Jira [реализация]

Части:
1. Условности
2. Реализация – вы тут
3. Автоматизации работы
4. Создание отчетов
5. Связь с другими проектами

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

В статье много картинок и имеет смысл её сначала прочесть целиком (а так же предыдущую часть, про условности), а потом повторить шаг за шагом.

Создание проекта

Проект добавляется через Administration > Projects > Add Project

Ключ проекта (Key) выбирать нужно обдуманно, потому что потом только его нельзя будет изменить. После создания проекта появится вот такая страница.

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

Чтобы не запутаться потом в схемах нужно сначала определить правила именования схем и полей. Например можно делать так:

Test Cases Название проекта
Test Cases Field Configuration Конфигурация полей
Test Cases Field Configuration Sheme Схема конфигурации полей

Во время написания статьи я использовал тот же принцип, только добавил название группы проектов перед его именем, получилось TC Demo.

Новые типы задач

Новые типы задач можно добавить через Administration > Issue Settings (слева колонка) > Issue Types > Add New Issue Type (в Jira 3 – внизу страницы). Нужно добавить два новых типа:

  1. TestCase, как Standard Issue Type, для хранения сценариев и прочих атрибутов тест кейса.
  2. Test, как Sub-Task Issue Type, для управления тестированием по тест кейсам.

Ради развлечения стоит поменять иконки (например взять из блока Адама Гушера, там обалденные жучки).

По умолчанию созданные типы задач сразу попадают в основную схему (Default Issue Type Scheme). Оттуда их можно убрать, но это не обязательно.

Там же, но на вкладке Issue Types Scheme нужно создать новую схему и ассоциировать с ней созданные типы задач. Не помешает так же задать TestCase как основной тип задач для этой схемы. Просто для экономии времени при заполнении в будущем.

После создания схема не будет привязана ни к одному из проектов. Установить эту схему для проекта можно прямо со страницы со списком схем, нажав Associate (если надо сразу несколько проектов добавить — самое то), либо через страницу администрирования проекта.

Дополнительные поля для тест кейсов

Дополнительные поля добавляются через Administration > Issue Fields (колонка слева) > Custom Fields > Add Custom Field

Полей потребуется всего четыре. Первые три, позволят хранить основные данные по тест кейсу.

Pre-conditions Free Text Field (unlimited text) Состояние системы до теста. В том числе настройки и специальные значения параметров.
Steps Free Text Field (unlimited text) Шаги теста
Post-conditions Free Text Field (unlimited text) Состояние системы после теста (если необходимо сравнивать).

По умолчанию значение всех полей такое (это разметка wiki):

|| Step || Action || Expected Result ||
| | | |

А отображаться будет вот так:

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

Test Case State Multi Select

Этот параметр может иметь сразу несколько значений. В сам список достаточно добавить Manual (выбрано по умолчанию) и Automated. В моём случае их комбинация позволяет определить состояние автоматизации тест кейса.

Manual Для ручного тестирования
Manual, Automated Показывает, что тест кейс либо отправлен на автоматизацию, либо автоматизирован, но так же его можно перепроверить руками (например, если тест часто падает или его результатам не доверяют, но и изменить или отключить его нельзя).
Automated Автоматический тест

В зависимости от условий эти поля можно привязать либо к определённому типу задач, либо к проекту, либо к тому и другому — для порядка.

Создание конфигурации полей

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

Если поле не предназначено для повсеместного использования, то лучше всего его привязать к типу задач, для которых оно предназначено. Задаётся привязка там же, где создаются дополнительные поля (Custom Fields). Выглядеть это будет так:

Правила отображения и обязательности полей

Эти правила задаются через Administration > Issue Fields (колонка слева) > Field Configuration. В действительности очень полезная вещь, которая позволяет избежать бардака. Там же задаётся видимость некоторых полей. Полезность этой настройки становится явной только когда срочно нужно отключить доступ к полю сразу во многих проектах, с одной схемой полей. В общем то больше административная вещь и её лучше не трогать при настройке проекта, если вы не уверены нужно ли это.

Так же, тут настраивается и отображение текстовых полей. Их можно показывать как обычный текст (Default Text Renderer), а можно как текст с wiki разметкой (Wiki Style Renderer). Wiki Style Renderer потребуется как раз для полей Pre & Post – conditions и Steps. Переключается режим отображения через ссылку “Renderers” для каждого поля.

Напрямую эти правила не используются, а включаются в состав схем полей (Field Configuration Scheme). Сразу при создании они не ассоциируются ни с одной схемой, ассоциации выставляются уже в схеме в которую включена конфиграция. Настроить схему можно через Administration > Issue Fields (колонка слева) > Field Configuration Scheme.

Field Configuration Scheme

Позволяет установить разные наборы полей для разных типов задач. Для этой реализации TCMS нет необходимости настраивать разные схемы полей на уровне конфигураций, это можно сделать на уровне представлений (Screen):

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

Создание разных видов отображения полей

Screen

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

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

Отображение полей при просмотре тест кейса и теста схожи:

TestCase (Demo TestCase Screen):
Test (sub-task, Demo Test Screen):

Screen Scheme

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

При создании схемы в качество основного отображения лучше выбрать то, которое отвечает за создание задачи и после отдельно указать отображение для просмотра. Для тест кейса (Demo TC Screen Scheme, для теста Demo T Screen Scheme точно так же объедияет отображение для теста – Demo Test Screen [create/edit] и Demo Test Screen [view]) эта связка будет выглядеть так:

Теперь эти схемы нужно связать с типами задач. Делается это с помощью Issue Type Screen Scheme. (Administration > Issue Fields (колонка слева) > Issue Type Screen Schemes).

И тут при создании новой схемы в качестве отображения по умолчанию выбрать просто Default Screen Scheme. Это обеспечит спокойное добавление новых типов задач и возможность быстро заметить направильные связи по схемам для них.

Подключаем все схемы в проект

На странице администрирования проекта через ссылки Select можно выбирать нужные схемы, получится примерно так:

Проверяем в работе

Если всё правильно то:

  • При создании или редактировании задачи (Create New Issue, Edit Issue):
    • при выборе проекта (Project) с тест кейсами в списке «Issue Type» будет только «TestCase».
    • форма с полями задачи содержит две вкладки — Base Information и Test Case. На вкладке Test Case видны четыре поля — Pre & Post Conditions, Steps, Test Case State. Для полей Pre & Post Conditions, Steps включён режим Wiki markup
  • При просмотре wiki разметка правильно отрабаытвается и видны все поля тест кейса, примерно так:

В качестве заключения

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

7 Comments

  1. Здравствуйте, подскажите как создать Screen для действия типа Create a sub-task. Не могу понять.

  2. Я не очень понимаю трудности с этим, процесс точно такой же как и для задач. Сейчас я не могу точно рассказать путь, потому что с Jira уже не работаю больше года и последнюю версию видел поверхностно. Но на странице связки типов задач и скринов нужно будет выбрать из списка нужный тип sub-task и для него назначить нужный Screen. Раньше это можно было сделать на той же странице со списком. Под ним была форма со всеми нужными данными.

    1. На странице Configure Screen Scheme. У меня в списке Issue Operation нет такого действия как создание подзадачи. Т.е. я не могу найти где этому действию можно сопоставить Screen.

      1. Мне сложно сейчас угадать где в интерфейсе это есть, не имея доступа. Вероятно вот эта ссылка может помочь http://confluence.atlassian.com/pages/viewpage.action?pageId=162038415 оттуда же http://confluence.atlassian.com/display/JIRA/Associating+a+Screen+with+an+Issue+Type
        Sub-task это такой же Issue type, что и просто Task, поэтому действия будут одинаковыми

Leave a Reply

Your email address will not be published. Required fields are marked *