Вводные данные. Наш продукт практически готов к отгрузке, осталось пройти приёмочное тестирование. Тест-план готов и представлен в виде таблицы Excel. Тестировать будут будущие пользователи, то есть, люди, далёкие от QA и IT.
Задача. Сделать всем удобно. Пользователи в теории должны прочитать описание, пройти тест и нажать кнопку «Пройдено». Программисты должны оперативно отреагировать на упавший тест и выложить исправление. Ну и графики-статистика само собой, чтобы менеджер понимал, где мы находимся.
Disclaimer. Разумеется, у QA в компании есть свой профессиональный инструментарий тестирования, спецификации, тест-кейсы и тд и тп. Но обычным пользователям нужно видеть только то, что нужно чтобы пройти тест. Заставлять их к примеру изучить Testlink это перебор.
Почему Jira? Потому что тикеты (далее я буду использовать именно этот термин в качестве issue) легко линкуются друг ко другу. И в запасе у крупной организации наверняка есть несколько неактивных аккаунтов (например, от уволившихся сотрудников или купленные про запас), которые можно выделить на пару недель для тестов. Все тесты будут в одном месте, ничего не придётся развёртывать дополнительно.
Итак собственно решение. Заводим отдельный проект для приёмочного тестирования. Импортируем в него тест-кейсы в виде тикетов. Рисуем красивые дашборды для пользователей и менеджмента. Делаем автоматическое создание багов при нажатие на кнопку Failed в тикете. Профит.
Проект подойдёт как новомодный next-gen, так и классический Software или даже Service Desk. Со «следующим поколением» всё просто, конфигурируется перетаскиванием мышкой минут за 15. Но есть одно но — нельзя модифицировать Workflow, соответственно невозможно изменить Transitions и мы теряем многие возможности автоматизации, не говоря о том, чтобы показать Transition screen при обнаружении бага.
Поэтому выбираем классический проект.
Тут всё просто. Три состояния Open, Passed и Failed. Переходы из любого состояния в Passed и Failed. При желании (для статистики) состояние Reopened, куда попадают тесты после исправления бага или подозрении на регрессию. Если Reopened не нужно, попадаем в Open соответственно, иначе Open будет только для новых тест-кейсов.
К переходу Failed прикручиваем простую форму без полей, чтобы пользователь мог ввести комментарий и приаттачить скриншот. На пост-функцию (post function) вешаем создание тикета в том же или соседнем проекте, куда копируем последний комментарий и линкуем по типу causes.
Workflow для бага выбирайте по своему вкусу. Но важно чтобы либо программист, либо скрипт вследствие выкладывания исправленной версии переводил бы залинкованные тикеты в состояние Reopened (или Opened). Тогда они автоматически попадают обратно в общую кучу тестов.
Тут городить ничего не надо, Jira всё умеет из коробки. Главное подготовить правильный CSV. А именно — каждый тикет это строчка, в заголовке желательно названия полей (чтобы не запутаться). Ну и если вам захотелось сгруппировать тест-кейсы по эпикам — ссылки на предварительно подготовленные тикеты эпиков.
Нестандартные поля (custom fields) готовим как обычно. Лично я чтобы не распухал REST-интерфейс создания тикета делаю всё по полной программе — создаю схему полей, удаляю всё, что к конкретному тикету не относится, добавляю новые поля только в нужной конфигурации. Да, запарно, зато сразу понятно какое поле к какому проекту относится и не возникает хаос. К тому же у нас многие любят называть поля одинаково, а потом поди догадайся почему тот или иной скрипт не работает. Если делать по уму, то неплохо помогает функция Where is my field — она детально показывает где вы накосячили и выдаёт ссылки на страницы конфигурации — очень удобно.
Однако мы отвлеклись. Если вы планируете использовать таблицы 2 dimensional в дашбордах, крайне рекомендую всё перечислимое сделать не строками, а именно Select single. Заполнить список легко — в Excel делаете Pivot по столбцу и набиваете значения в Jira custom field.
Про сам процесс импорта. Тут всё просто. В средней колонке выбираете имя поля в Jira, в правой — будет ли значение преобразовываться при импорте (Mapping) или просто скопируется как есть. Для Single Selection я рекомендую оставить Mapping value, чисто чтобы убедиться что всё в порядке. Для всего остального можно не «маппить».
Например, есть у нас 4 поля — Описание теста, Пререквизиты, Шаги и Планируемый результат. Делаем колонку Description и суммируем поля с помощью оператора & или если вам так нравится Concatenate. Для переноса строки используем CHAR(10). Для ненужных пользователю полей вставляем таблицу. Заголовки и сами знаете — h1. Для безусловного переноса строки (нужен перед таблицей) ставим \\. Всё, описание теста готово, читай и выполняй. Да, чтобы вся разметка попала в Jira, нужно отключить mapping для Value для этого поля (он и так отключен, так что просто не включайте).
Ссылку на другой тикет сделать просто. Название столбца — Link 'blocks', содержание — ключ тикета. При маппинге выбираем правильный тип ссылки.
Ну и последнее о чём стоило бы упомянуть — это то, что максимальное количество тикетов для импорта в Jira не может превышать 250. Если больше — тупо копируем таблицу по строкам на листы и сохраняем в отдельные файлы CSV. Я лично чтобы не запутаться обзываю их 1-250.csv, 251-500.csv и так далее.
Как и в любом другом деле дашбордстроения лучше всего заранее подготовить фильтры. Особенно если тестирование у вас будет многофазовое. Тогда чтобы подготовить дашборд другой фазы достаточно будет скопировать дашборд и повесить другие фильтры.
Мне лично нравятся такие гаджеты:
Пользователям можно дать ссылку на дашборд и сказать «черпайте тикеты из таблицы Status vs Component» из колонок Open и Reopen. Выбираете тикет, читаете описание, выполняете и кликаете Passed или Failed. Если Failed, в окошко вбиваете комментарий, желательно с картинкой (Alt-PrintScreen, Shift+Ins). Всё.
Ничего необычного, делаем как всегда. Разве что я бы порекомендовал завести отдельную схему и дать права конкретным пользователям на конкретные операции, не включая их в группы. Тогда и в другие проекты не залезут, и вычистить будет легко (просто сменив схему на стандартную). И да, после завершения тестирования пользователей делаем неактивными, возвращая лицензии в систему.
В общем-то и всё. В целом настройка проекта для UAT-тестирования потребует часа четыре, а развёртывание существующего проекта под другие тесты — минут 15. И не надо ничего устанавливать.
Задача. Сделать всем удобно. Пользователи в теории должны прочитать описание, пройти тест и нажать кнопку «Пройдено». Программисты должны оперативно отреагировать на упавший тест и выложить исправление. Ну и графики-статистика само собой, чтобы менеджер понимал, где мы находимся.
Disclaimer. Разумеется, у QA в компании есть свой профессиональный инструментарий тестирования, спецификации, тест-кейсы и тд и тп. Но обычным пользователям нужно видеть только то, что нужно чтобы пройти тест. Заставлять их к примеру изучить Testlink это перебор.
Почему Jira? Потому что тикеты (далее я буду использовать именно этот термин в качестве issue) легко линкуются друг ко другу. И в запасе у крупной организации наверняка есть несколько неактивных аккаунтов (например, от уволившихся сотрудников или купленные про запас), которые можно выделить на пару недель для тестов. Все тесты будут в одном месте, ничего не придётся развёртывать дополнительно.
Итак собственно решение. Заводим отдельный проект для приёмочного тестирования. Импортируем в него тест-кейсы в виде тикетов. Рисуем красивые дашборды для пользователей и менеджмента. Делаем автоматическое создание багов при нажатие на кнопку Failed в тикете. Профит.
Детали реализации
Проект подойдёт как новомодный next-gen, так и классический Software или даже Service Desk. Со «следующим поколением» всё просто, конфигурируется перетаскиванием мышкой минут за 15. Но есть одно но — нельзя модифицировать Workflow, соответственно невозможно изменить Transitions и мы теряем многие возможности автоматизации, не говоря о том, чтобы показать Transition screen при обнаружении бага.
Поэтому выбираем классический проект.
Workflow
Тут всё просто. Три состояния Open, Passed и Failed. Переходы из любого состояния в Passed и Failed. При желании (для статистики) состояние Reopened, куда попадают тесты после исправления бага или подозрении на регрессию. Если Reopened не нужно, попадаем в Open соответственно, иначе Open будет только для новых тест-кейсов.
К переходу Failed прикручиваем простую форму без полей, чтобы пользователь мог ввести комментарий и приаттачить скриншот. На пост-функцию (post function) вешаем создание тикета в том же или соседнем проекте, куда копируем последний комментарий и линкуем по типу causes.
минутка рекламы
Ни в коей мере не будучи связан с авторами плагина категорически рекомендую JMWE для задач автоматизации. Исключительно гибкий инструмент, написать можно любой сценарий, какой только вздумается понимаюшему в извращениях месье. Работает без проблем, есть режим тестирования и логирования
Workflow для бага выбирайте по своему вкусу. Но важно чтобы либо программист, либо скрипт вследствие выкладывания исправленной версии переводил бы залинкованные тикеты в состояние Reopened (или Opened). Тогда они автоматически попадают обратно в общую кучу тестов.
Импорт тест кейсов
Тут городить ничего не надо, Jira всё умеет из коробки. Главное подготовить правильный CSV. А именно — каждый тикет это строчка, в заголовке желательно названия полей (чтобы не запутаться). Ну и если вам захотелось сгруппировать тест-кейсы по эпикам — ссылки на предварительно подготовленные тикеты эпиков.
Нестандартные поля (custom fields) готовим как обычно. Лично я чтобы не распухал REST-интерфейс создания тикета делаю всё по полной программе — создаю схему полей, удаляю всё, что к конкретному тикету не относится, добавляю новые поля только в нужной конфигурации. Да, запарно, зато сразу понятно какое поле к какому проекту относится и не возникает хаос. К тому же у нас многие любят называть поля одинаково, а потом поди догадайся почему тот или иной скрипт не работает. Если делать по уму, то неплохо помогает функция Where is my field — она детально показывает где вы накосячили и выдаёт ссылки на страницы конфигурации — очень удобно.
Однако мы отвлеклись. Если вы планируете использовать таблицы 2 dimensional в дашбордах, крайне рекомендую всё перечислимое сделать не строками, а именно Select single. Заполнить список легко — в Excel делаете Pivot по столбцу и набиваете значения в Jira custom field.
Про сам процесс импорта. Тут всё просто. В средней колонке выбираете имя поля в Jira, в правой — будет ли значение преобразовываться при импорте (Mapping) или просто скопируется как есть. Для Single Selection я рекомендую оставить Mapping value, чисто чтобы убедиться что всё в порядке. Для всего остального можно не «маппить».
Лайфхак
Помним что у нас не простые пользователи, вернее, простые, ни разу не работавшие в Jira. Поэтому чем меньше полей — тем лучше. В идеале всё описание тест-кейса можно завернуть в Description, благо псевдовики-разметка поддерживается в полной мере.Например, есть у нас 4 поля — Описание теста, Пререквизиты, Шаги и Планируемый результат. Делаем колонку Description и суммируем поля с помощью оператора & или если вам так нравится Concatenate. Для переноса строки используем CHAR(10). Для ненужных пользователю полей вставляем таблицу. Заголовки и сами знаете — h1. Для безусловного переноса строки (нужен перед таблицей) ставим \\. Всё, описание теста готово, читай и выполняй. Да, чтобы вся разметка попала в Jira, нужно отключить mapping для Value для этого поля (он и так отключен, так что просто не включайте).
Ссылку на другой тикет сделать просто. Название столбца — Link 'blocks', содержание — ключ тикета. При маппинге выбираем правильный тип ссылки.
Ну и последнее о чём стоило бы упомянуть — это то, что максимальное количество тикетов для импорта в Jira не может превышать 250. Если больше — тупо копируем таблицу по строкам на листы и сохраняем в отдельные файлы CSV. Я лично чтобы не запутаться обзываю их 1-250.csv, 251-500.csv и так далее.
Дашборд
Как и в любом другом деле дашбордстроения лучше всего заранее подготовить фильтры. Особенно если тестирование у вас будет многофазовое. Тогда чтобы подготовить дашборд другой фазы достаточно будет скопировать дашборд и повесить другие фильтры.
Мне лично нравятся такие гаджеты:
- Two dimensional
— Status vs Component - Filter Counts
— мало кто догадывается, но там можно повесить абсолютно любой JQL, например, общее количество багов по компоненте. - Issue Statistics
— просто статусы тикетов в процентах. - Activity Stream
— по данному проекту
Пользователям можно дать ссылку на дашборд и сказать «черпайте тикеты из таблицы Status vs Component» из колонок Open и Reopen. Выбираете тикет, читаете описание, выполняете и кликаете Passed или Failed. Если Failed, в окошко вбиваете комментарий, желательно с картинкой (Alt-PrintScreen, Shift+Ins). Всё.
Добавление пользователей
Ничего необычного, делаем как всегда. Разве что я бы порекомендовал завести отдельную схему и дать права конкретным пользователям на конкретные операции, не включая их в группы. Тогда и в другие проекты не залезут, и вычистить будет легко (просто сменив схему на стандартную). И да, после завершения тестирования пользователей делаем неактивными, возвращая лицензии в систему.
В общем-то и всё. В целом настройка проекта для UAT-тестирования потребует часа четыре, а развёртывание существующего проекта под другие тесты — минут 15. И не надо ничего устанавливать.