![](https://engineer.yadro.com/wp-content/uploads/2024/06/testy_cover.png)
Ролевая модель и интеграция c Jira: что изменилось в системе для управления тестами, которая доступна всем
![](https://engineer.yadro.com/wp-content/uploads/2024/06/testy_cover.png)
В конце прошлого года мы представили TestY, систему для управления с открытым исходным кодом на замену TestRail. За шесть месяцев мы улучшили систему и реализовали полезный функционал в новой версии. Например, разграничили права на просмотр и управление проектами, добавили возможность дублировать существующие тест-планы, чтобы не тратить время на заполнение похожих, и еще семь других фич.
В этой статье Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TestY, расскажет о каждом изменении и о том, как оно повлияет на удобство использования TMS.
![](https://engineer.yadro.com/wp-content/uploads/2024/06/testy_cover.png)
- какие запросы поступили разработчикам TMS от пользователей и что удалось реализовать
- как работает role based access control
- какой логике подчиняется легковесная интеграция с Jira
- какие еще фичи появились в новом релизе
Конфигурация для production
Начну с того, что мы добавили конфигурацию для production-среды, где контент отдается с помощью nginx. Это упростит развертывание среды и уменьшит нагрузку на бэкенд системы. Правда, сначала потребуется указать пути до SSL-сертификата. По умолчанию до релиза 1.2.14 шел только docker-compose для разработки.
Колонки Estimate и Labels в списке тестов тестового плана
В вывод списка тестов тест-плана по умолчанию добавили две новые колонки — Estimate (оценка времени) и Labels (метки), которые упрощают поиск нужных тестов. Теперь можно искать тесты с нужными параметрами: по наличию estimate или с определенным набором меток.
![Отображение колонок в списке тестов](https://engineer.yadro.com/wp-content/uploads/2024/06/1_testy_labels-1024x490.png)
Кастомные атрибуты
Изначально мы не планировали реализовывать кастомные атрибуты (в других TMS их иногда называет кастомными полями) в тестовых кейсах и считали, что добавить дополнительную информацию можно через метки (Labels). Тем не менее, после анализа запросов от пользователей решили, что такой функционал нужен, но реализуем мы его на более общем уровне — уровне проекта.
Теперь в рамках конфигурирования проекта можно добавить собственные атрибуты, которые будут отображаться в каждом тестовом кейсе или тестовом результате этого проекта, — их применимость можно выбрать. Помимо стандартных полей Setup, Scenario, Teardown, Description, Estimate, Labels, вы можете добавить любые необходимые, например, Defects, Links и другие.
Помимо этого, появилась возможность настроить набор кастомных атрибутов на уровне всего проекта или для специфичного сьюта. Такие атрибуты можно сделать обязательными для заполнения или опциональными.
Преимущество кастомных атрибутов в том, что можно создать нужные именно вашему проекту поля, которые не будут отображаться у других пользователей. А создатели плагинов могут добавить кастомные атрибуты, нужные для их работы.
![Настройки для кастомных атрибутов](https://engineer.yadro.com/wp-content/uploads/2024/06/2_testy_custom_field-1024x489.png)
![Кастомные атрибуты в тестовом результате](https://engineer.yadro.com/wp-content/uploads/2024/06/3_testy_create_result-1024x492.png)
Создание и редактирование тестовых кейсов на отдельной вкладке
Раньше создавать и редактировать тестовый кейс нужно было в модальном окне. Но когда появился механизм добавления кастомных атрибутов на уровне проекта, окно стало выглядеть перегруженным. В версии 1.3 мы отказались от модального окна и вынесли создание и редактирование тестовых кейсов на отдельную вкладку.
![Вкладка для создания и редактирования тестовых кейсов](https://engineer.yadro.com/wp-content/uploads/2024/06/4_testy_testcase-1024x497.png)
Выбор тестов при создании тестового плана
Доработали набор тестов в план на этапах создания и изменения. Теперь пользователям доступен не только поиск по названию, но и фильтрация по лейблам.
Фильтрация доступна как на «и» так и на «или»: можно искать как тест-кейсы с определенным сочетанием лейблов, так и те, в которых встречается хотя бы один из них. Новый механизм значительно упрощает процесс набора тестов в план. Особенно актуально для команд с большим количеством сценариев и развитой системой меток.
![Фильтрация по лейблам](https://engineer.yadro.com/wp-content/uploads/2024/06/5_testy_test_plan-1024x490.png)
RBAC (role based access control)
Когда TestY только запустился, мы не хотели давать пользователям разные права и ограничивать доступ к проектам, так как считали важным, что каждый мог посмотреть, как устроены тесты в других продуктах. Тем более, при необходимости пользователи TestY могли написать плагин для контроля доступа на основе ролей.
Но в процессе работы с TestY необходимость RBAC появилась сама собой. Сначала одна из внутренних команд YADRO попросила реализовать ролевую модель из-за конфиденциальной информации в проекте, а потом в другой команде появились сотрудники на аутсорсе, доступ которых должен был ограничиться конкретным проектом.
Так появились роли:
- Super Admin — классическая глобальная роль с доступом ко всем проектам.
- Admin — роль, которая управляет доступом к конкретному проекту, добавляет пользователей и настраивает время на редактирование тестовых результатов.
- User — пользователь проекта.
- External User — роль для внешних пользователей с доступом только к тем проектам, в которых он работает.
При необходимости в будущем можно будет создать новые роли — например, выделить группу пользователей, которой доступно только создание тестовых результатов. Включить RBAC в проектах, созданных в версии TestY от 1.3 и выше, может Super Admin. Для новых проектов опция работает в момент создания.
![Открытые и приватные проекты](https://engineer.yadro.com/wp-content/uploads/2024/06/6_testy_private-1024x492.png)
![Роли, которые мы добавили в проекты](https://engineer.yadro.com/wp-content/uploads/2024/06/7_testy_roles-1024x490.png)
Копирование тестового плана
Добавили копирование тестов из существующего тестового плана в новый без сохранения результатов. Это достаточно популярный и востребованный функционал в TMS, позволяющий быстро создавать копию плана и вносить в него изменения. Например, если в ваших тестах повторяются планы регрессии, можно скопировать тесты для них из предыдущего релиза и не тратить время на создание с нуля.
Также по многочисленным просьбам добавили возможность сохранять assignment тестов (назначение на конкретных пользователей) при копировании плана, которая может понадобиться на проектах с более или менее жесткой привязкой областей ответственности тестировщиков.
![Модальное окно для копирования тестового плана](https://engineer.yadro.com/wp-content/uploads/2024/06/8_testy_modal-1024x490.png)
Легковесная интеграция с Jira
В прошлом тексте мы упоминали, что одна из мотиваций сделать проект с открытым исходным кодом — это развитие системы плагинов вокруг TestY силами инженерного комьюнити, в том числе разработка плагина для интеграции с Jira. Пока внешние пользователи не создали такой плагин, но запросы на него поступали от коллег так часто, что мы решили написать простой аналог. Со стороны Jira решение реализовано с помощью расширения View через iframe.
Работает так: тикеты с типом Bug линкуются со связанными тестовыми результатами из TestY. Линки отображаются в поле TestY Results. Префикс «А» означает, что тестовый результат находится в архиве.
При добавлении нового тестового результата необходимо добавить атрибут Defects с типом list и в качестве значения атрибута добавить ссылку на один или несколько Jira-тикетов.
Ссылку на каждый новый тикет нужно добавлять с новой строки.
Функциональность будет работать и для результатов, добавленных в прошлом, если использован соответствующий атрибут (Defects).
У выбранного решения есть ряд очевидных недостатков, но на текущем этапе они нивелируются простотой реализации и встраивания в Jira. Это может быть важным для организаций со сложными процессами внесения изменений в корпоративные информационные системы.
Это же решение можно применить и для других задач. Например, визуализации покрытия требований.
![Интеграция с Jira](https://engineer.yadro.com/wp-content/uploads/2024/06/9_testy_jira-1-1024x590.png)
Редактирование тестовых результатов
Ранее изменять статус тестового результата можно было в течение часа после сохранения, чтобы пользователи могли исправить случайные ошибки. Затем тестовый результат замораживается, и править его больше нельзя. Чем больше команд подключались к нашей TMS, тем сильнее мы убеждались, что часа на редактирование недостаточно, а добавлять новый корректный тестовый результат не всегда удобно.
В новой версии мы вынесли параметр редактирования в настройки проекта. Теперь его администратор может выбрать одну из трех опций:
- запретить изменение результатов,
- разрешить изменение результатов в течение заданного промежутка времени (интервал каждый выбирает сам в зависимости от процессов в конкретном проекте, по умолчанию это все еще час),
- разрешить бессрочное изменение результатов (просто не указывать интервал времени).
![Настройки редактируемости тестового результата](https://engineer.yadro.com/wp-content/uploads/2024/06/10_testy_edit-1024x492.png)
Остаемся на связи
Инженеры YADRO и других компаний активно пользуются TMS TestY почти полтора года. За это время система закрыла базовые потребности, которые появились после прекращения выдачи лицензий TestRail. Тем не менее, мы получаем много внутренних и внешних запросов на расширение функциональности и доработку существующих функций.
В конце 2023 года мы организовали архитектурный комитет, где обрабатываем входящие запросы и составляем роадмап развития TestY. Нам есть над чем работать, и мы делаем это с удовольствием.