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

Сегодня на связи я, Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TMS TestY. После первого текста о нашей системе вы обращались к моим коллегам с вопросами и пожеланиями — спасибо, что подтвердили, что она востребована и интересна. Некоторые озвученные предложения мы уже планировали в новый релиз, но были и те, что мы взяли в работу именно благодаря вашей обратной связи. В этой статье расскажу о фичах, вышедших в релизе 1.3, и отвечу на вопросы о TestY в комментариях.

Знаете, как сделать 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. Это может быть важным для организаций со сложными процессами внесения изменений в корпоративные информационные системы.

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

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

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

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

• запретить изменение результатов,

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

• разрешить бессрочное изменение результатов (просто не указывать интервал времени).

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

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

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

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