По сути, вы хотите создать тип проблемы под названием «Тестовый случай». Дайте ему рабочий процесс, который запускается Open -> Pass и Open -> Fail. Когда контрольный пример был выполнен, регистрируется сборка, дата, время и так далее. Если это не удается, зарегистрируйте ту же информацию и откройте дефект. В моей реализации я использую Jira Create и Link , чтобы упростить создание дефекта, связать его с контрольным примером и предварительно заполнить его соответствующей информацией. После устранения дефекта контрольный пример должен вернуться в состояние «открыто», чтобы его можно было повторно запустить.
Хитрость заключается в отслеживании выполнения во времени. Есть множество способов пойти. Вы можете создать поле с именем «Build Tested» и обновлять его при каждом запуске тестового примера. Другой способ - написать скрипт для публикации истории выполнения во внешней системе, такой как Confluence.
В моей реализации у меня есть два типа контрольных примеров: «Контрольный пример» и «Регрессивный контрольный пример». Первые являются подзадачами пользовательских историй и относятся к новым функциям. Последние относятся к тестам существующих функций.
Что касается группировки, проще всего было бы использовать поля «Компонент» и «Метки» для группировки тестовых случаев. Таким образом, вы можете искать историю выполнения следующим образом:
issuetype="TestCase" AND labels in (Installer, Linux, GUI) ORDER BY "Build Tested"