Привет, Хабр! Меня зовут Дмитрий Ткач, я руководитель разработки инструментов для тестирования в компании YADRO.
В прошлом году TestRail прекратил предоставлять и продлевать лицензии компаниям из России, поэтому мы решили разработать собственную тест-менеджмент систему TestY. Опирались на опыт работы с другими сервисами, чтобы добавить тот функционал, которого не хватало нашим командам тестирования. За несколько месяцев написали core-часть системы и выложили ее в open source, чтобы другие компании и разработчики, для которых актуален вопрос лицензионной чистоты используемого софта, пользовались решением и развивали его.
Под катом расскажу об отличиях TestY от других TMS и преимуществах нашей системы для команд любого размера. Спойлер: в TestY могут одновременно работать 300 тестировщиков — система справляется. Для тех, кто хочет опробовать TestY в своей команде, в конце статьи есть короткая инструкция, как ее развернуть.
Если вам больше нравятся живые выступления или вы хотите узнать о Testy в видеоформате, посмотрите выступление Дмитрия на конференции Heisenbug.
![](https://habrastorage.org/getpro/habr/upload_files/860/f4b/8ca/860f4b8ca3f90e1e025078ade60be2ab.jpeg)
Чем можно было заменить 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.
![Форма описания тест-кейса. Форма описания тест-кейса.](https://habrastorage.org/getpro/habr/upload_files/d00/b8f/54e/d00b8f54e08277b10ca9678794399d52.jpeg)
Поля формы поддерживают Markdown: можно вставлять код, таблицы, добавлять приложения без ограничений в размере и формате. В TestY вложения находятся за авторизацией — без аутентификации приложения не посмотреть, что повышает безопасность системы. Также все прикрепленные файлы отдаются как статика — это меньше грузит систему на быстрых дисках и повышает ее производительность.
Описать сценарий теста можно двумя способами: свободным описанием в одном поле и через шаги (Steps). В первом случае мы прогоняем все действия, описанные в сценарии, и сверяем полученный результат с ожидаемым (Expected). Во втором — прописываем ожидаемый результат для каждого шага сценария и сверяемся с ним в каждой точке теста.
Из тест-кейсов собираются тестовые планы.
Тестовый план
Тоже знакомая пользователям TMS сущность. План — это подмножество тест-кейсов, выбранных вручную или автоматически через встроенную API для:
изменений, которые попадают в релиз
общего согласованного списка кейсов, которые можно протестировать к определенному дедлайну
В интерфейсе TestY при создании тест-плана можно выбрать тест-кейсы, соответствующие задаче.
Тестовые планы в TestY заменяют сразу несколько сущностей, знакомых пользователям TestRail: майлстоуны, тестовые раны, тестовые планы для комбинированных результатов. Такое сложносочиненное деление всегда казалось нам излишним.
В системе есть тест-планы и опция вложенности — а дальше пользователь сам решает, как организовывать структуру своих тестов. Уровней вложенности может быть сколько угодно, но, исходя из нашего опыта, деревом глубиной больше трех планов сложно управлять.
![Форма описания тестового плана. Форма описания тестового плана.](https://habrastorage.org/getpro/habr/upload_files/689/ec8/4b9/689ec84b9af9e7c7dc7d455d1eb03494.jpeg)
Естественно, после выполнения теста в TestY можно указать его статус: Passed, Failed, Broken и так далее. Для оценки успешности работы есть удобная визуализация, показывающая число проведенных тестов и их разделение по статусу и оценке по времени.
![Визуализация для тестового плана. Визуализация для тестового плана.](https://habrastorage.org/getpro/habr/upload_files/618/646/82b/61864682b930e605a7edcdd3a434485c.jpeg)
Параметризация тест-планов
В TestRail было неудобно прогонять один и тот же тест-план по нескольким параметрам. Мы сделали так, что в настройках тест-плана пользователь может добавить столько параметров, сколько нужно. Эта опция пригодится для команд, которые, например, тестируют сервис на разных операционных системах и хотят отследить изменения прохождения тестов в разных конфигурациях.
![Добавление параметров. Добавление параметров.](https://habrastorage.org/getpro/habr/upload_files/ec5/d00/e29/ec5d00e29caac117aed30b381da9f4a0.jpeg)
У инструмента удобный UI — вы выбираете из списка заданных параметров, а не вводите вручную, то есть исключаете описки. Когда создаете тестовый план с параметрами, на выходе получаете список уже параметризированных тестовых планов. Плюс к этому добавлена оптимизация по поиску: легко найти тестовый план с нужной параметризацией.
![Список параметризированных тест-планов. Список параметризированных тест-планов.](https://habrastorage.org/getpro/habr/upload_files/fdb/127/529/fdb127529cb0be76922975fbdadeefe1.jpeg)
Кастомные атрибуты для тестовых результатов
Мы заменили привычные кастомные поля тестовых результатов на кастомные атрибуты — настраиваемые категории, которые помогут зафиксировать результат теста максимально подробно. В TestY пользователь может добавить к карточке тестового результата любое описание — при этом, в отличие от полей, оно не будет отображаться в каждом тестовом результате.
![Кастомные атрибуты. Кастомные атрибуты.](https://habrastorage.org/getpro/habr/upload_files/cff/394/246/cff39424695e0aebda5adcbea2d1ca60.jpeg)
Версионирование тест-кейсов
Этой функциональности не хватало в TestRail, и мы добавили ее в TestY. Версионирование тестовых кейсов пригодится, когда:
во время прохождения тестового плана нужно поменять тестовый сценарий,
хочется видеть, к какой версии тест-кейса относятся результаты.
Новая версия тест-кейса создается автоматически каждый раз, когда пользователь обновляет информацию в карточке. Тем не менее, мы учли человеческий фактор и добавили опцию «обновить тест-кейс без обновления версии».
![Разные версии одного и того же тест-плана. Разные версии одного и того же тест-плана.](https://habrastorage.org/getpro/habr/upload_files/07e/a0c/d9a/07ea0cd9a844e099b3ceebb6d0731f78.png)
В TestRail была опция: можно было перевести сущность в архивную. В первом релизе TestY мы сделали такой же. Когда вышли в продакшен, команды уже начали реализовывать тестовые планы, часть из которых теряла актуальность со временем. Мы решили сделать так, чтобы при желании пользователь мог архивировать целый тест-план. Однако нужно учесть, что она затрагивает всю ветку вложенности, включая тесты и результаты. Но архивация — не удаление, к архивированным сущностям всегда можно вернуться.
Метки
Метки (Labels) для тест-кейсов помогают делать быстрые срезы по тестовым результатам. В одном тестовом плане могут быть разные виды тестов: автоматические, ручные, для определенных клиентов или функций. Мы хотели иметь возможность собирать статистику по разным видам тестов в одном окне и гибко управлять визуализацией результатов.
![Метки с опцией Condition. Метки с опцией Condition.](https://habrastorage.org/getpro/habr/upload_files/622/19b/8b5/62219b8b5f28a55985b3f4f27dce98b4.jpeg)
Также мы добавили опцию Condition — с ее помощью можно показывать все кейсы с одинаковыми метками и собирать по ним статистику. Простой и в то же время очень мощный функционал. Например, аккаунт-менеджер хочет посмотреть, как выполнялись тест-кейсы по его проекту, — он выбирает метку, и TMS показывает сводку данных по всем тестам с ней.
При изменении меток в тестовом плане также делается инкремент версии. Это значит, что всегда можно посмотреть, какие метки были добавлены в разных версиях.
Инструменты для миграции из других TMS
Чтобы командам было проще мигрировать свои проекты в нашу систему, мы написали три плагина, доступные в open source:
![Импортер из TestRail. Импортер из TestRail.](https://habrastorage.org/getpro/habr/upload_files/bf3/19f/c03/bf319fc03306c44fdd35facbfa04357d.png)
Импортер из 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. Страница входа в TMS.](https://habrastorage.org/getpro/habr/upload_files/b49/ae0/00f/b49ae000fc59b753560e16cdcfb477ea.jpeg)
Для полноценной работы TestY с примерно 20 проектами отлично подойдет виртуальная машина с 4 vCPU, 4 ГБ RAM и 30 ГБ дисковой памяти. Но она работает и на менее производительном сервере — мы тестировали систему на конфигурации 1 vCPU, 2 ГБ RAM, 2 ГБ дисковой памяти. Небольшим командам тестировщиков вполне этого хватит для работы.
Вы также получите доступ к плагинам-миграторам, чтобы быстро и удобно переехать из TestRail или Excel, а также загрузить Allure-отчеты.
TestY распространяется под лицензией AGPLv3. Эта лицензия требует предоставлять исходный код, в том числе при модификации. Если пользователь изменил систему и выложил в интернет — должен дать ссылку на исходный код. Однако на плагины это не распространяется: вы можете написать плагин под другой лицензией и свободно опубликовать — или не публиковать вообще, если там содержится конфиденциальная информация о вашей компании.
YADRO — не разработчик софта для тестирования, и у тестировщиков много задач, связанных с продуктами компании. Именно поэтому мы хотим привлечь внимание комьюнити к этому решению, которое кажется нам простым в использовании, гибким и эффективным. С вашей помощью эта TMS может обрастать новой функциональностью и стать отличной заменой проприетарных решений для самых разных компаний. Лично я надеюсь, что кто-нибудь из вас напишет крутую интеграцию с Jira.
А пока задавайте вопросы по системе, тестируйте ее и отмечайте в комментариях и опросе, про какую часть TMS вы хотите узнать больше.