программы

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

58
0
10 июня 2024
Изображение создано с помощью нейросети
программы
58
0
10 июня 2024
Ролевая модель и интеграция c Jira: что изменилось в системе для управления тестами, которая доступна всем

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

В этой статье Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TestY, расскажет о каждом изменении и о том, как оно повлияет на удобство использования TMS.

Изображение создано с помощью нейросети
Из статьи вы узнаете
  • какие запросы поступили разработчикам TMS от пользователей и что удалось реализовать
  • как работает role based access control
  • какой логике подчиняется легковесная интеграция с Jira
  • какие еще фичи появились в новом релизе
Если хотите добавить TestY в свой продукт или знаете, как улучшить систему, пишите на testy@yadro.com

Конфигурация для production

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

Колонки Estimate и Labels в списке тестов тестового плана

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

Отображение колонок в списке тестов
Отображение колонок в списке тестов

Кастомные атрибуты

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

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

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

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

Настройки для кастомных атрибутов
Настройки для кастомных атрибутов: можно сделать их обязательными для всего проекта или ограничиться одним сьютом
Кастомные атрибуты в тестовом результате
Кастомные атрибуты в тестовом результате

Создание и редактирование тестовых кейсов на отдельной вкладке

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

Вкладка для создания и редактирования тестовых кейсов
Вкладка для создания и редактирования тестовых кейсов

Выбор тестов при создании тестового плана

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

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

Фильтрация по лейблам
Фильтрация по лейблам

RBAC (role based access control)

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

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

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

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

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

Открытые и приватные проекты
Открытые и приватные проекты
Роли, которые мы добавили в проекты
Роли, которые мы добавили в проекты

Копирование тестового плана

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

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

Модальное окно для копирования тестового плана
Модальное окно для копирования тестового плана

Легковесная интеграция с Jira

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

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

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

Функциональность будет работать и для результатов, добавленных в прошлом, если использован соответствующий атрибут (Defects).

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

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

Интеграция с Jira
Интеграция с Jira

Редактирование тестовых результатов

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

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

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

Остаемся на связи

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

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

Если ваша команда все еще ведет отчеты по тестированию в Excel, Confluence, Wiki и не пользуется полноценной тест-менеджмент системой, попробуйте TestY.
Наверх
Будь первым, кто оставит комментарий