На рынке (и в OpenSource) достаточно специализированных систем для тестирования, хороший обзор например здесь. Есть и опытные специалисты по тестированию которые предпочитают старый добрый Excel. В принципе, выбор рабочего инструмента — прерогатива профессионала, в чём удобнее, в том и работаю. Но что если сделать инструмент самому — на базе используемого разработчиками софта?

Под катом — как это можно сделать в Jira.

Итак, у нас есть лицензированная Jira (любителям Open Source вполне можно договориться с Atlassian или использовать Developer's version из SDK). Естественно, QA инженеры имеют доступ, им же нужно постить баги. Почему бы не завести проект под тестовые сценарии и сделать не хуже чем в TestRail?

Вводные условия

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

Желательно также иметь плагин скриптинга в Jira, чтобы автоматически проводить тикеты по шагам в зависимости от событий. Я лично предпочитаю вот этот , но у вас скорее всего уже всё есть, нужно только порасспрашивать программистов.

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

Чего мы хотим

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

Поехали

Создаём новый проект Test Scenarios. Каждый сценарий у нас будет отдельным тикетом. Каждый шаг сценария — подзадачей.

1. Смотрим на таблицу со сценариями и создаём все Custom Fields, которые нам потребуются. Если у программистов они уже есть — ещё легче, записываем их названия, они нам пригодятся при импорте.


2. Формируем в таблице колонки Summary и Description.
Summary для шагов должен выглядеть примерно так: Описание шага — Результат
Description это плод вашей фантазии. Но очень хорошо знать разметку Jira и активно использовать таблицы, ссылки на пользователей, заголовки и тд и тп. Ничего экранировать не надо, Jira скушает и не подавится.

Пример разметки: = «h1. » & A2 & " h2. " & B2 & "\\||Col1||Col2||" & CHAR(10) & "|" & C2 & "|" & D2 & "|"

Перенос строки — CHAR(10), жёсткий перенос строки в Jira (нужен перед таблицами) — \\

3. Для каждой строчки заводим номера тикета и родителя. С номером тикета всё просто — сквозная нумерация начиная с 1 (в принципе может быть любой уникальный идентификатор, не важно). Родитель пустой у сценария, а у шага — номер сценария. Формула в Excel тривиальная.

4. Если вы заведёте отдельные названия для тикетов в Jira вместо стандартных Task и Sub task — понадобится колонка для названия типа тикета.

5. Сохраняем всё в CSV в формате UTF-8. Импортируем через меню администратора (поищите Import в окне поиска). Главное замапить ваши колонки на правильные поля.

Нужно ещё помнить что Jira не умеет имортировать более 250 строчек за раз, так что возможно что придётся разбить таблицу на несколько.

Итак, мы получили несколько десятков сценариев, в каждом из которых много шагов-подзадач. Чем это хорошо для нас?

Открываем сценарий. Все шаги внизу сценария. Всё что нужно сделать — кликнуть на… и выбрать переход у подзадачи в состояние Passed или Failed. Два клика для успеха — неплохо.

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

Тут нам понадобится плагин. Я описываю как я это делаю в JMWE.

В Workflow для Sub task находим Transition из Open в Failed и создаём Post Function для создания нового бага. Копируем нужные поля, последний комментарий и аттачменты. Выполняем от имени текущего пользователя. Сохраняем.

Добавляем Transition Screen. Он в принципе может быть пустым — если вам достаточно комментария. Или содержать другие поля.

Теперь когда вы переводите Sub task из Open в Failed — выскакивает окошко, куда вы вводите описание бага, аттачите скриншот и заполняете другие поля по вкусу — и девелоперы получают баг, приаттаченный к конкретному шагу сценария. Удобно — сразу видно кто сделал баг, как, где и когда. Никакой копипасты.

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

Исправление бага

Один из вариантов — как только баг исправлен и доступен для тестирования, программист переводит упавший тест в состояние Open и QA может продолжать тестирование. Если подозревается регрессия — находим соответствующие сценарии и подзадачи и с помощью Bulk Update переводим из Done в Open.

Версионирование

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

Версия железа. Её можно засунуть в свойства пользователя Jira. Например, у Вани Пупкина Android 9.0.1 и телефон Asus Zen 12, а у Лены Игнатовой розовый Iphone X и iOS 1.4.3. Скрипт прочитает поля пользователя и автоматически вставит в баг.

Выводы

Специализированные системы это хорошо, особенно для специалистов по тестированию, но это может быть неудобно для программистов. Excel тоже неплох, если тестировщик всего один. Jira это инструмент разработчика, но настроить его чтобы было удобно специалисту QA вполне можно. И мы получим наглядность и скорость тестирования от TestRail, возможность табличного представления Excel, а также полную интеграцию с проектами разработки.