Ролевая модель и интеграция c Jira: что изменилось в системе для управления тестами, которая доступна всем

Начну с того, что мы добавили конфигурацию для production-среды, где контент отдается с помощью nginx. Это упростит развертывание среды и уменьшит нагрузку на бэкенд системы. Правда, сначала потребуется указать пути до SSL-сертификата. По умолчанию до релиза 1.2.14 шел только docker-compose для разработки.

В вывод списка тестов тест-плана по умолчанию добавили две новые колонки — Estimate (оценка времени) и Labels (метки), которые упрощают поиск нужных тестов. Теперь можно искать тесты с нужными параметрами: по наличию estimate или с определенным набором меток.

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

Теперь в рамках конфигурирования проекта можно добавить собственные атрибуты, которые будут отображаться в каждом тестовом кейсе или тестовом результате этого проекта, — их применимость можно выбрать. Помимо стандартных полей Setup, Scenario, Teardown, Description, Estimate, Labels, вы можете добавить любые необходимые, например, Defects, Links и другие.

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

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

Раньше создавать и редактировать тестовый кейс нужно было в модальном окне. Но когда появился механизм добавления кастомных атрибутов на уровне проекта, окно стало выглядеть перегруженным. В версии 1.3 мы отказались от модального окна и вынесли создание и редактирование тестовых кейсов на отдельную вкладку.

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

Фильтрация доступна как на «и» так и на «или»: можно искать как тест-кейсы с определенным сочетанием лейблов, так и те, в которых встречается хотя бы один из них. Новый механизм значительно упрощает процесс набора тестов в план. Особенно актуально для команд с большим количеством сценариев и развитой системой меток.

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

Но в процессе работы с TestY необходимость RBAC появилась сама собой. Сначала одна из внутренних команд YADRO попросила реализовать ролевую модель из-за конфиденциальной информации в проекте, а потом в другой команде появились сотрудники на аутсорсе, доступ которых должен был ограничиться конкретным проектом.

Так появились роли:

• Super Admin — классическая глобальная роль с доступом ко всем проектам.
• Admin — роль, которая управляет доступом к конкретному проекту, добавляет пользователей и настраивает время на редактирование тестовых результатов.
• User — пользователь проекта.
• External User — роль для внешних пользователей с доступом только к тем проектам, в которых он работает.

При необходимости в будущем можно будет создать новые роли — например, выделить группу пользователей, которой доступно только создание тестовых результатов. Включить RBAC в проектах, созданных в версии TestY от 1.3 и выше, может Super Admin. Для новых проектов опция работает в момент создания.

Добавили копирование тестов из существующего тестового плана в новый без сохранения результатов. Это достаточно популярный и востребованный функционал в TMS, позволяющий быстро создавать копию плана и вносить в него изменения. Например, если в ваших тестах повторяются планы регрессии, можно скопировать тесты для них из предыдущего релиза и не тратить время на создание с нуля.

Также по многочисленным просьбам добавили возможность сохранять assignment тестов (назначение на конкретных пользователей) при копировании плана, которая может понадобиться на проектах с более или менее жесткой привязкой областей ответственности тестировщиков.

В прошлом тексте мы упоминали, что одна из мотиваций сделать проект с открытым исходным кодом — это развитие системы плагинов вокруг TestY силами инженерного комьюнити, в том числе разработка плагина для интеграции с Jira. Пока внешние пользователи не создали такой плагин, но запросы на него поступали от коллег так часто, что мы решили написать простой аналог. Со стороны Jira решение реализовано с помощью расширения View через iframe.

Работает так: тикеты с типом Bug линкуются со связанными тестовыми результатами из TestY. Линки отображаются в поле TestY Results. Префикс «А» означает, что тестовый результат находится в архиве.

При добавлении нового тестового результата необходимо добавить атрибут Defects с типом list и в качестве значения атрибута добавить ссылку на один или несколько Jira-тикетов.

У выбранного решения есть ряд очевидных недостатков, но на текущем этапе они нивелируются простотой реализации и встраивания в Jira. Это может быть важным для организаций со сложными процессами внесения изменений в корпоративные информационные системы.

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

Ранее изменять статус тестового результата можно было в течение часа после сохранения, чтобы пользователи могли исправить случайные ошибки. Затем тестовый результат замораживается, и править его больше нельзя. Чем больше команд подключались к нашей TMS, тем сильнее мы убеждались, что часа на редактирование недостаточно, а добавлять новый корректный тестовый результат не всегда удобно.

В новой версии мы вынесли параметр редактирования в настройки проекта. Теперь его администратор может выбрать одну из трех опций:

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

Инженеры YADRO и других компаний активно пользуются TMS TestY почти полтора года. За это время система закрыла базовые потребности, которые появились после прекращения выдачи лицензий TestRail. Тем не менее, мы получаем много внутренних и внешних запросов на расширение функциональности и доработку существующих функций.

В конце 2023 года мы организовали архитектурный комитет, где обрабатываем входящие запросы и составляем роадмап развития TestY. Нам есть над чем работать, и мы делаем это с удовольствием.