TMS на замену TestRail: писали для себя, а выложили в open source
Привет, Хабр! Меня зовут Дмитрий Ткач, я руководитель разработки инструментов для тестирования в компании YADRO.
В прошлом году TestRail прекратил предоставлять и продлевать лицензии компаниям из России, поэтому мы решили разработать собственную тест-менеджмент систему TestY. Опирались на опыт работы с другими сервисами, чтобы добавить тот функционал, которого не хватало нашим командам тестирования. За несколько месяцев написали core-часть системы и выложили ее в open source, чтобы другие компании и разработчики, для которых актуален вопрос лицензионной чистоты используемого софта, пользовались решением и развивали его.
Под катом расскажу об отличиях TestY от других TMS и преимуществах нашей системы для команд любого размера. Спойлер: в TestY могут одновременно работать 300 тестировщиков — система справляется. Для тех, кто хочет опробовать TestY в своей команде, в конце статьи есть короткая инструкция, как ее развернуть.
Чем можно было заменить TestRail
Раньше команды тестирования в YADRO пользовались тест-менеджмент системой TestRail. Это популярный инструмент с множеством опций и возможностью интеграции с другими сервисами — например, Jira. TestRail никогда не был полностью подходящей нам по функциональности системой, но мы приспособились, написали вспомогательные инструменты и работали так долгое время.
Весной 2022 года компания Gurock, владелец TestRail, перестала продлевать лицензии и оказывать поддержку пользователям из России. Мы начали думать, чем заменить TestRail, и пришли к следующим вариантам.
Одна из существующих TMS с открытым исходным кодом
Open source-систем тест-менеджмента достаточно мало. Инструменты либо старые и уже не поддерживаются, либо новые, но со специфическим функционалом, который нельзя расширять привычным способом — например, с помощью плагинов.
Единственное решение, которое нам понравилось, — это Kiwi TCMS. Система от Kiwi живая, с активным комьюнити. Одна из команд в YADRO развернула решение, перевела на него несколько проектов и собрала обратную связь. Функционала Kiwi TCMS объективно не хватало: например, не было разделения на проекты, кастомных статусов и Rest API.
Отечественное коммерческое решение
Лидер среди российских TMS — Test IT. Мы получили демо-доступ и перевели туда несколько проектов, чтобы понять, подойдет ли эта система для наших задач.
На момент мая 2022 года функциональности Test IT под нашу специфику тестирования тоже не хватило — например, снова не было кастомных статусов. Если с частью ограничений мы были готовы смириться или подождать реализацию в будущих версиях, то несколько вещей серьезно ухудшали качество работы команд тестирования. Например, в эту TMS нельзя перенести историю прохождения тестовых планов из TestRail. Поскольку это важные в работе данные, инженерам бы пришлось постоянно обращаться к старой системе, что совсем не удобно. Так мы отказались от Test IT.
Собственная TMS
Поиск нового решения совпал с ростом численности команд разных направлений YADRO, инженеров стало больше — и уже дешевле создать внутренний инструмент под наши требования, чем покупать лицензии стороннего софта на всю команду.
Название для системы придумали студенты матмеха СПбГУ, которые участвовали в разработке TestY в ходе стажировки в нашей компании. В названии есть отсылка к компании (Y — 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: какие фичи добавили и от чего отказались
Для каждой команды или продукта в TestY предусмотрен отдельный проект. Внутри проект разделен на тест-сьюты — папки, в которые собираются тестовые кейсы. Как устроена дальнейшая структура TMS и какой функционал мы разработали для пользователей, расскажу в этом разделе.
Тест-кейсы
Структура описания тест-кейса в TestY не отличается от стандартного для того же TestRail.
Форма описания тест-кейса.
Поля формы поддерживают Markdown: можно вставлять код, таблицы, добавлять приложения без ограничений в размере и формате. В TestY вложения находятся за авторизацией — без аутентификации приложения не посмотреть, что повышает безопасность системы. Также все прикрепленные файлы отдаются как статика — это меньше грузит систему на быстрых дисках и повышает ее производительность.
Описать сценарий теста можно двумя способами: свободным описанием в одном поле и через шаги (Steps). В первом случае мы прогоняем все действия, описанные в сценарии, и сверяем полученный результат с ожидаемым (Expected). Во втором — прописываем ожидаемый результат для каждого шага сценария и сверяемся с ним в каждой точке теста.
Из тест-кейсов собираются тестовые планы.
Тестовый план
Тоже знакомая пользователям TMS сущность. План — это подмножество тест-кейсов, выбранных вручную или автоматически через встроенную API для:
изменений, которые попадают в релиз
общего согласованного списка кейсов, которые можно протестировать к определенному дедлайну
В интерфейсе TestY при создании тест-плана можно выбрать тест-кейсы, соответствующие задаче.
Тестовые планы в TestY заменяют сразу несколько сущностей, знакомых пользователям TestRail: майлстоуны, тестовые раны, тестовые планы для комбинированных результатов. Такое сложносочиненное деление всегда казалось нам излишним.
В системе есть тест-планы и опция вложенности —, а дальше пользователь сам решает, как организовывать структуру своих тестов. Уровней вложенности может быть сколько угодно, но, исходя из нашего опыта, деревом глубиной больше трех планов сложно управлять.
Форма описания тестового плана.
Естественно, после выполнения теста в TestY можно указать его статус: Passed, Failed, Broken и так далее. Для оценки успешности работы есть удобная визуализация, показывающая число проведенных тестов и их разделение по статусу и оценке по времени.
Визуализация для тестового плана.
Параметризация тест-планов
В TestRail было неудобно прогонять один и тот же тест-план по нескольким параметрам. Мы сделали так, что в настройках тест-плана пользователь может добавить столько параметров, сколько нужно. Эта опция пригодится для команд, которые, например, тестируют сервис на разных операционных системах и хотят отследить изменения прохождения тестов в разных конфигурациях.
Добавление параметров.
У инструмента удобный UI — вы выбираете из списка заданных параметров, а не вводите вручную, то есть исключаете описки. Когда создаете тестовый план с параметрами, на выходе получаете список уже параметризированных тестовых планов. Плюс к этому добавлена оптимизация по поиску: легко найти тестовый план с нужной параметризацией.
Список параметризированных тест-планов.
Кастомные атрибуты для тестовых результатов
Мы заменили привычные кастомные поля тестовых результатов на кастомные атрибуты — настраиваемые категории, которые помогут зафиксировать результат теста максимально подробно. В TestY пользователь может добавить к карточке тестового результата любое описание — при этом, в отличие от полей, оно не будет отображаться в каждом тестовом результате.
Кастомные атрибуты.
Версионирование тест-кейсов
Этой функциональности не хватало в TestRail, и мы добавили ее в TestY. Версионирование тестовых кейсов пригодится, когда:
во время прохождения тестового плана нужно поменять тестовый сценарий,
хочется видеть, к какой версии тест-кейса относятся результаты.
Новая версия тест-кейса создается автоматически каждый раз, когда пользователь обновляет информацию в карточке. Тем не менее, мы учли человеческий фактор и добавили опцию «обновить тест-кейс без обновления версии».
Разные версии одного и того же тест-плана.
В TestRail была опция: можно было перевести сущность в архивную. В первом релизе TestY мы сделали такой же. Когда вышли в продакшен, команды уже начали реализовывать тестовые планы, часть из которых теряла актуальность со временем. Мы решили сделать так, чтобы при желании пользователь мог архивировать целый тест-план. Однако нужно учесть, что она затрагивает всю ветку вложенности, включая тесты и результаты. Но архивация — не удаление, к архивированным сущностям всегда можно вернуться.
Метки
Метки (Labels) для тест-кейсов помогают делать быстрые срезы по тестовым результатам. В одном тестовом плане могут быть разные виды тестов: автоматические, ручные, для определенных клиентов или функций. Мы хотели иметь возможность собирать статистику по разным видам тестов в одном окне и гибко управлять визуализацией результатов.
Метки с опцией Condition.
Также мы добавили опцию Condition — с ее помощью можно показывать все кейсы с одинаковыми метками и собирать по ним статистику. Простой и в то же время очень мощный функционал. Например, аккаунт-менеджер хочет посмотреть, как выполнялись тест-кейсы по его проекту, — он выбирает метку, и TMS показывает сводку данных по всем тестам с ней.
При изменении меток в тестовом плане также делается инкремент версии. Это значит, что всегда можно посмотреть, какие метки были добавлены в разных версиях.
Инструменты для миграции из других TMS
Чтобы командам было проще мигрировать свои проекты в нашу систему, мы написали три плагина, доступные в open source:
Импортер из TestRail.
Импортер из TestRail. Позволяет быстро переехать в TestY вместе с историей тестирования и приложенными к кейсам файлами.
Allure Uploader. Этот инструмент дает пользователям возможность загружать результаты прогонов из Allure-репортов. В TestY конкретный Allure-отчет загружается со своим идентификатором. К одному тесту можно добавить несколько тестовых результатов с различными статусами. Они все связаны, есть история, и по всей статистике системы отображается последний добавленный тестовый результат.
Excel-мигратор. Есть команды, которые ведут свои проекты в Excel. Для них тоже есть есть плагин для быстрого переезда.
Результаты использования TestY в YADRO
За 9 месяцев в продакшене у нас получились вот такие результаты:
все команды тестирования YADRO переехали в TestY,
запустили более 20 проектов,
получили более 500 тысяч тестовых результатов.
Система справляется с нагрузкой, а мы убедились, что правильно сделали, выбрав Django под наши задачи.
Что нужно, если вы хотите начать пользоваться TestY
Развернуть TestY можно за несколько шагов:
Перед установкой TMS убедитесь, что у вас есть Git, Docker и Docker Compose.
Клонируйте репозиторий.
Перейдите в директорию репозитория и скопируйте переменные окружения.
cd ./testy && cp .env.template .envЗапустите docker-compose up.
docker-compose up -dПосле запуска всех контейнеров TMS TestY будет доступна по адресу
http://127.0.0.1:3007.Для входа администратора можно использовать дефолтные пароли admin: password (их можно переопределить в .env).
Страница входа в TMS.
Для полноценной работы TestY с примерно 20 проектами отлично подойдет виртуальная машина с 4 vCPU, 4 ГБ RAM и 30 ГБ дисковой памяти. Но она работает и на менее производительном сервере — мы тестировали систему на конфигурации 1 vCPU, 2 ГБ RAM, 2 ГБ дисковой памяти. Небольшим командам тестировщиков вполне этого хватит для работы.
Вы также получите доступ к плагинам-миграторам, чтобы быстро и удобно переехать из TestRail или Excel, а также загрузить Allure-отчеты.
TestY распространяется под лицензией AGPLv3. Эта лицензия требует предоставлять исходный код, в том числе при модификации. Если пользователь изменил систему и выложил в интернет — должен дать ссылку на исходный код. Однако на плагины это не распространяется: вы можете написать плагин под другой лицензией и свободно опубликовать — или не публиковать вообще, если там содержится конфиденциальная информация о вашей компании.
YADRO — не разработчик софта для тестирования, и у тестировщиков много задач, связанных с продуктами компании. Именно поэтому мы хотим привлечь внимание комьюнити к этому решению, которое кажется нам простым в использовании, гибким и эффективным. С вашей помощью эта TMS может обрастать новой функциональностью и стать отличной заменой проприетарных решений для самых разных компаний. Лично я надеюсь, что кто-нибудь из вас напишет крутую интеграцию с Jira.
А пока задавайте вопросы по системе, тестируйте ее и отмечайте в комментариях и опросе, про какую часть TMS вы хотите узнать больше.
