Привет! Я Александр Зырянов, проектный менеджер 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

TestY 2.0 — скоро

Комментарии (2)


  1. user8021
    03.10.2024 06:59

    Интеграция с LDAP, аутентификация через OIDC планируется?


    1. dmitkach
      03.10.2024 06:59
      +5

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

      • Устанавливается пакет django-auth-ldap

      pip install django-auth-ldap
      
      • Добавляется backend для аутентификации в настройки Django

      AUTHENTICATION_BACKENDS = [
          "django_auth_ldap.backend.LDAPBackend",
          "django.contrib.auth.backends.ModelBackend",
      ]
      
      • Указывается обязательные настройки

      AUTH_LDAP_SERVER_URI = 'ldap://your_hostname_or_ip:389'
      AUTH_LDAP_BIND_DN = '<lookup_user_name>'
      AUTH_LDAP_BIND_PASSWORD = '<lookup_user_secret>'
      AUTH_LDAP_GROUP_SEARCH = LDAPSearch(...)
      

      Готово

      Поиск групп, маппинг и другое настраивается отдельно, полную документацию можно почитать тут: https://django-auth-ldap.readthedocs.io/en/latest/

      OIDC не планируется.