Привет! Я Александр Зырянов, проектный менеджер TestY и QA-менеджер в департаменте контроля качества YADRO. Тест-менеджмент системе TestY, которая доступна в open source любой команде и компании, скоро два года. За это время мы обработали десятки обращений внешних пользователей и тестировщиков нашей компании. Сделали систему более удобной для использования: автоматизировали рутинные операции и кастомизировали разделы, где может играть роль специфика тестирования конкретной компании.
Мы готовим крупный релиз 2.0 с масштабными изменениями системы, в том числе дизайна интерфейса. А пока в качестве «аппетайзера» я расскажу про последние обновления к релизу 1.3.4. Среди них — bulk-операции, пуш-уведомления пользователей, доработка кастомных атрибутов и статусов.
Доработали функциональность кастомных атрибутов
В прошлом тексте я рассказывал про версию 1.3, одной из ключевых фичей которой была возможности создания кастомных атрибутов (кастомных полей) для тест-кейсов и тестовых результатов. Изменение было на 100% полезно для пользователей, а его активная эксплуатация подсветила ограничения, которые мы быстро устранили.
В TestY 1.3 и новее можно на уровне проекта создать кастомные поля, обязательные или необязательные для заполнения при создании тест-кейсов и/или добавлении тестовых результатов.
В версии 1.3 мы учли, что набор полей может отличаться в зависимости от сущности, к которой относится поле (тест-кейс/тестовый результат), а также набора, в котором находится тест-кейс. Но мы не подумали, что набор полей может и зачастую будет зависеть от статуса тестового результата.
Например, поле Defects, добавленное к тестовым результатам, должно быть обязательным при статусе Failed, но при успешном прохождении теста (Passed) в принципе не требуется.
Теперь при создании или редактировании атрибута можно указать, к каким статусам он будет применяться.
Добавили кастомные статусы тестовых результатов
В продолжение темы кастомизации и тестовых результатов. За прошедший год мы получили NN-ое количество запросов на добавление статусов к результатам: Passed with bugs, In Progress, Deferred и других. Архитектурный комитет TestY решил продолжать двигаться в сторону кастомизации сущностей: не добавлять отдельные статусы, а позволить пользователю настроить проект, исходя из потребностей. Поэтому с версии 1.3.3 мы добавили и доработали возможность создания кастомных статусов.
В TestY по-прежнему есть дефолтный набор системных статусов и зарезервированное название отсутствия статуса — Untested. Но в дополнение администратор проекта может создать любое количество собственных статусов и задать им порядок отображения. Кастомные статусы доступны для выбора только в рамках проекта, в котором они добавлены.
Работая над кастомными статусами, мы изменили поведение при добавлении нового тестового результата и добавили ему (поведению) вариативности. Теперь по умолчанию статус тестового результата и статусы шагов (для тестов с шагами) остаются не заполненными. При желании администратор проекта может выбрать дефолтный статус.
Например, если сделать дефолтным статусом Passed, поведение системы будет аналогичным поведению в более ранних версиях. То есть при добавлении нового тестового результата, его статус и статус шагов будут сразу выставлены в Passed. Это сэкономит время на ручное проставление результатов. Однако, если тест в итоге упадет, нужно будет поменять статус с автоматически проставленного Passed на Failed.
Также мы добавили кнопку Apply to steps на форму добавления/изменения тестового результата, которая подставляет выбранный статус тестового результата во все шаги. И, разумеется, сохранили возможность поменять статус отдельного шага/шагов.
Реализовали клонирование тестовых результатов
Функциональность значительно упрощает жизнь, особенно если при добавлении результата нужно заполнить много кастомных атрибутов.
При нажатии на кнопку Clone открывается форма добавления результата с подставленными значениями, которые можно отредактировать перед сохранением. Если от результата к результату, например, меняется только билд, достаточно клонировать предыдущий результат, поменять билд на актуальный и сохранить, не тратя время на заполнение остальных полей.
Добавили нотификации для пользователей
В текущей реализации можно получать Web Push-уведомления о назначении тестов (test assigned) и снятии их с себя (test unassigned). Нотификации настраиваются для конкретного пользователя — во вкладке Settings по клику на колокольчик (в правом верхнем углу).
Реализовали перенос тестов из одного плана в другой
Мы столкнулись с тем, что при планировании тестов и тестировании продукта не всегда понятна окончательная структура тест-планов. Особенно для продуктов, релизный цикл которых предполагает длительные итерации. В таком случае может возникнуть потребность переноса уже пройденных тестов из одного плана в другой.
Мы реализовали такую возможность: с версии 1.3.2 пользователь может переместить тест из одного плана в другой в рамках проекта. При этом вместе с тестом «переедут» и ассоциированные с ним результаты.
Добавили возможность выполнять массовые операции
Выполнение bulk-операций — это второй по частоте запрос пользователей после кастомизации сущностей. Мы начали работу в этом направлении и в первом приближении реализовали массовые операции для переноса (Move tests) и назначения (Assign To) тестов. Операции доступны в разделе Test Plans & Results, для использования нужно отметить нужные тесты из списка.
Повысили производительность системы
Последнее по порядку, но не последнее по важности — улучшение TestY на бэкенде. Эти изменения не бросаются в глаза пользователям, но позитивно сказываются на пользовательском опыте. За полтора года использования TestY в YADRO мы ожидаемо столкнулись с трудностями, связанными с ограничениями производительности при определенных сценариях использования нашей TMS. Чем дальше в лес, тем больше дров, а в лес мы зашли глубоко и останавливаться не собираемся.
Мы постоянно работаем над оптимизацией работы бэкенда и пробуем разные варианты. Подробнее про свежий опыт — ускорение Django-rest-framework — можно прочитать в статье нашего разработчика.
В декабре-январе мы планируем масштабный релиз TestY 2.0 для внешних пользователей. До этого протестируем обновление внутри компании. Развернуть TestY можно за несколько минут через файл docker compose. Подробнее об установке и миграции тестов в нашу бесплатную систему читайте здесь. А об интеграции с Jira — здесь. Все вопросы по системе можно отправлять на почту testy@yadro.com.
user8021
Интеграция с LDAP, аутентификация через OIDC планируется?
dmitkach
Мы не добавляли в core часть аутентификацию через LDAP, во-первых, не всем компаниям необходимо, а во-вторых правила в каждой компании отличаются. Но, это делается довольно быстро и просто, как мы сделали у себя:
Устанавливается пакет django-auth-ldap
Добавляется backend для аутентификации в настройки Django
Указывается обязательные настройки
Готово
Поиск групп, маппинг и другое настраивается отдельно, полную документацию можно почитать тут: https://django-auth-ldap.readthedocs.io/en/latest/
OIDC не планируется.