TMS на замену TestRail: писали для себя, а выложили в open source

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

Весной 2022 года компания Gurock, владелец TestRail, перестала продлевать лицензии и оказывать поддержку пользователям из России. Мы начали думать, чем заменить TestRail, и пришли к следующим вариантам.

Open source-систем тест-менеджмента достаточно мало. Инструменты либо старые и уже не поддерживаются, либо новые, но со специфическим функционалом, который нельзя расширять привычным способом — например, с помощью плагинов.

Единственное решение, которое нам понравилось, — это Kiwi TCMS. Система от Kiwi живая, с активным комьюнити. Одна из команд в YADRO развернула решение, перевела на него несколько проектов и собрала обратную связь. Функционала Kiwi TCMS объективно не хватало: например, не было разделения на проекты, кастомных статусов и Rest API.

Лидер среди российских TMS — Test IT. Мы получили демо-доступ и перевели туда несколько проектов, чтобы понять, подойдет ли эта система для наших задач.

На момент мая 2022 года функциональности Test IT под нашу специфику тестирования тоже не хватило — например, снова не было кастомных статусов. Если с частью ограничений мы были готовы смириться или подождать реализацию в будущих версиях, то несколько вещей серьезно ухудшали качество работы команд тестирования. Например, в эту TMS нельзя перенести историю прохождения тестовых планов из TestRail. Поскольку это важные в работе данные, инженерам бы пришлось постоянно обращаться к старой системе, что совсем не удобно. Так мы отказались от Test IT.

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

Перед стартом разработки TMS мы собрали все формальные требования от разных команд тестирования в YADRO. Выделю основные из них.

Как я писал выше, разработка TestY совпала с ростом компании. К нам присоединились команды тестирования из R&D-центров глобальных компаний — им нужна была TMS, которая выдержит миллион тестовых результатов, более 200 проектов и 300 активных пользователей одновременно.

Мы разрабатывали TMS TestY в короткие сроки и под собственные задачи, поэтому в первую очередь мы реализовали классические для таких систем core-функции: добавление и управление тест-сьютами, тест-кейсами, тестовыми планами и т. д. Дополнительный функционал можно дописать самостоятельно в виде плагинов: отчеты, нотификации, интеграция с другими системами.

Так, пользователи TestY могут написать собственные нотификации, репорты, роли (IAM). Например, некоторые команды YADRO разработали систему оповещений, которая подходит именно им. Этих плагинов в open source-версии нет, поскольку в коде есть конфиденциальная информация и много связей с внутренней инфраструктурой компании.

Мы выбрали стек и экосистему на Python, Django по нескольким причинам. Во-первых, у нас есть экспертиза в Python и ряд решений на Django, которые уже хорошо работают внутри компании. Во-вторых, Python — один из самых популярных языков для написания тестов. Open source-проект на доступном многим пользователям языке привлечет больше разработчиков — они легко смогут писать плагины для расширения системы.

Для каждой команды или продукта в TestY предусмотрен отдельный проект. Внутри проект разделен на тест-сьюты — папки, в которые собираются тестовые кейсы. Как устроена дальнейшая структура TMS и какой функционал мы разработали для пользователей, расскажу в этом разделе.

Структура описания тест-кейса в TestY не отличается от стандартного для того же TestRail.

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

Описать сценарий теста можно двумя способами: свободным описанием в одном поле и через шаги (Steps). В первом случае мы прогоняем все действия, описанные в сценарии, и сверяем полученный результат с ожидаемым (Expected). Во втором — прописываем ожидаемый результат для каждого шага сценария и сверяемся с ним в каждой точке теста.

Из тест-кейсов собираются тестовые планы.

Тоже знакомая пользователям TMS сущность. План — это подмножество тест-кейсов, выбранных вручную или автоматически через встроенную API для:

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

В интерфейсе TestY при создании тест-плана можно выбрать тест-кейсы, соответствующие задаче.

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

В системе есть тест-планы и опция вложенности — а дальше пользователь сам решает, как организовывать структуру своих тестов. Уровней вложенности может быть сколько угодно, но, исходя из нашего опыта, деревом глубиной больше трех планов сложно управлять.

Естественно, после выполнения теста в TestY можно указать его статус: Passed, Failed, Broken и так далее. Для оценки успешности работы есть удобная визуализация, показывающая число проведенных тестов и их разделение по статусу и оценке по времени.

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

У инструмента удобный UI — вы выбираете из списка заданных параметров, а не вводите вручную, то есть исключаете описки. Когда создаете тестовый план с параметрами, на выходе получаете список уже параметризированных тестовых планов. Плюс к этому добавлена оптимизация по поиску: легко найти тестовый план с нужной параметризацией.

Мы заменили привычные кастомные поля тестовых результатов на кастомные атрибуты — настраиваемые категории, которые помогут зафиксировать результат теста максимально подробно. В TestY пользователь может добавить к карточке тестового результата любое описание — при этом, в отличие от полей, оно не будет отображаться в каждом тестовом результате.

А еще мы реализовали загрузку отчетов из Allure. В TestY конкретный Allure-отчет загружается со своим идентификатором. К одному тесту можно добавить несколько тестовых результатов с различными статусами. Они все связаны, есть история, и по всей статистике системы отображается последний добавленный тестовый результат.

Этой функциональности не хватало в TestRail, и мы добавили ее в TestY. Версионирование тестовых кейсов пригодится, когда:

• во время прохождения тестового плана нужно поменять тестовый сценарий,
• хочется видеть, к какой версии тест-кейса относятся результаты.

Новая версия тест-кейса создается автоматически каждый раз, когда пользователь обновляет информацию в карточке. Тем не менее, мы учли человеческий фактор и добавили опцию «обновить тест-кейс без обновления версии».

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

Метки (Labels) для тест-кейсов помогают делать быстрые срезы по тестовым результатам. В одном тестовом плане могут быть разные виды тестов: автоматические, ручные, для определенных клиентов или функций. Мы хотели иметь возможность собирать статистику по разным видам тестов в одном окне и гибко управлять визуализацией результатов.

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

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

Чтобы командам было проще мигрировать свои проекты в нашу систему, мы написали три плагина, доступные в open source:

• Импортер из TestRail
  Позволяет быстро переехать в TestY вместе с историей тестирования и приложенными к кейсам файлами.
• Allure Uploader
  Этот инструмент дает пользователям возможность загружать результаты прогонов из Allure-репортов.
• Excel-мигратор
  Есть команды, которые ведут свои проекты в Excel. Для них тоже есть плагин для быстрого переезда.

За 9 месяцев в продакшене у нас получились вот такие результаты:

• все команды тестирования YADRO переехали в TestY,
• запустили более 20 проектов,
• получили более 500 тысяч тестовых результатов.

Система справляется с нагрузкой, а мы убедились, что правильно сделали, выбрав Django под наши задачи.

Развернуть TestY можно за несколько шагов:

1. Перед установкой TMS убедитесь, что у вас есть Git, Docker и Docker Compose.
2. Клонируйте репозиторий.
3. Перейдите в директорию репозитория и скопируйте переменные окружения.
4. Запустите docker-compose up.
5. После запуска всех контейнеров TMS TestY будет доступна по этому адресу: http://127.0.0.1:3007.
6. Для входа администратора можно использовать дефолтные пароли admin: password (их можно переопределить в .env).

Для полноценной работы TestY с примерно 20 проектами отлично подойдет виртуальная машина с 4 vCPU, 4 ГБ RAM и 30 ГБ дисковой памяти. Но она работает и на менее производительном сервере — мы тестировали систему на конфигурации 1 vCPU, 2 ГБ RAM, 2 ГБ дисковой памяти. Небольшим командам тестировщиков вполне этого хватит для работы.

Вы также получите доступ к плагинам-миграторам, чтобы быстро и удобно переехать из TestRail или Excel, а также загрузить Allure-отчеты.

TestY распространяется под лицензией AGPLv3. Эта лицензия требует предоставлять исходный код, в том числе при модификации. Если пользователь изменил систему и выложил в интернет — должен дать ссылку на исходный код. Однако на плагины это не распространяется: вы можете написать плагин под другой лицензией и свободно опубликовать — или не публиковать вообще, если там содержится конфиденциальная информация о вашей компании.

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

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