Как выбрать и внедрить TMS в банке. Опыт ООО «РСХБ-Интех»

Даже правильно выбранная TМS нуждается в кастомизации. В современном мире банки всё больше становятся похожи на IT-компании. Например, в них появляются позиции: «аналитик», «разработчик», «тестировщик». 

Я, Марина Каприз, занимаю должность заместителя руководителя Блока обеспечения качества и выпуска изменений ПО в ООО «РСХБ-Интех», расскажу, как в Россельхозбанке происходил переход к автоматизированной системе управления тестированием.

В самом начале в банке как таковой отдельной профессиональной структуры тестирования не было, хотя IT-продукты и появлялись. Функцию тестирования выполняли разработчики и аналитики. Затем была создана дочерняя структура ООО «РСХБ-Интех», которая стала заниматься цифровой трансформацией и новыми технологиями. В новой компании стали формироваться отделы для разработки различных продуктов. Они со временем разрастались, и начали выделяться роли тестировщиков. Гораздо позже на эти роли стали подбирать людей с соответствующими компетенциями. Таким образом, тестирование в «РСХБ –Интех» развивалось параллельно в разных подразделениях, каждое из которых имело свою методологию. Данные по тестированию обобщались с помощью Excel и Word. Это было долго, сложно, и затягивало процесс выпуска изменений IT-продуктов.

Чтобы быстрее выпускать качественные IT-продукты, в «РСХБ-Интех» был сформирован Блок обеспечения качества и выпуска изменений ПО (далее Блок), перед которым была поставлена задача объединить все виды тестирования и выстроить эффективные процессы. Мы разработали единый методологический стандарт процесса, в то числе ведения тестовой документации. Но поскольку тестовые модели, особенно регрессионные, были очень объёмными, работа по приведению их к единой структуре и формату грозила растянуться на многие годы. Логично было перейти к использованию TMS.

Итак, опираясь на опыт, мы сформулировали основные требования к системе. В ней должны быть: 

• хранение тестовой документации в единых структуре, формате и пространстве;

• управление тестированием: запуск тестовых сценариев, фиксация результатов прогонов тестовых сценариев – как ручных, так и автоматизированных;

• экспорт / импорт тестовой документации в форматах Word и Excel; 

• возможность двухсторонней синхронизации с JIRA с целью заведения дефектов непосредственно в системе;

• возможность для менеджеров тестирования равномерно распределять нагрузку между сотрудниками;

• контроль времени прохождения кейсов исполнителем;

• выгрузка отчетности.

Для любителей покопаться в деталях приводим подробные требования:

Как мы выбирали TMS

Мы стали изучать рынок. Определили наиболее популярные системы: «TestRail», «Adaptavist», «Microfocus ALM», «Test IT». Изучили их возможности и занесли в таблицу:

Проанализировав таблицу, мы поняли, что «TestRail» нам не подходит, поскольку в нём отсутствовал критичный для Блока функционал по синхронизации дефектов и миграции описания сценариев в JIRA, а также возможность создания общих шагов. Позже из тройки лидеров выпал и «Adaptavist», поскольку у него не оказалось «Метрики среднего времени прохождения и падения автотестов» и статистики по сотрудникам, что для нас было критичным: мы планируем в дальнейшем повышать скорость и качество тестирования, а также точность планирования.  

Таким образом, мы выбирали между «Test IT» и «Microfocus ALM». Но поскольку разница в цене была существенной, мы выбрали «Test IT», тем более, что эта система российская и соответствует интересам Россельхозбанка по импортозамещению. Большим плюсом было то, что компания-разработчик «Test IT» была готова дорабатывать свое коробочное решение под потребности «РСХБ-Интех».

То есть по функционалу эта система максимально нам подходила, да еще и была в разы дешевле. Но мы сомневались из-за того, что «Test IT» является менее популярным продуктом. Когда же на сайте «Test IT» мы увидели информацию о том, что «ВТБ» и «Дом.рф» пользуются этой системой, сомнения развеялись. Крупные банки вряд ли стали бы использовать ненадёжный продукт.

Внедрение. Для сисадминов

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

Решить эту проблему помогли разработчики «Test IT». Они разработали утилиту на языке C#, которая переводит все тест-кейсы в Excel-файлы, разбивает их на части и формирует запрос на отправку сообщения по API. При этом на стороне «Test IT» создаются тест-кейсы в указанном в поле ProjectId, в результате чего в пользовательском интерфейсе проекта отображаются загруженные тестовые сценарии.

Создание утилиты позволило исключить ручное заведение имеющихся тест-кейсов / чек-листов в систему «Test IT», что сократило время внедрения программного обеспечения Блоком. Миграция тестовых моделей по всем системам заняла 4 месяца.

 Позднее импорт / экспорт был реализован из пользовательского интерфейса, и теперь менеджеры проектов могут загружать данные в проекты «Test IT» без помощи администраторов: 

Внедрение. Для разработчиков автотестов

Следующая трудность – существующий стэк, который использовался в Блоке, не позволял запускать автотесты непосредственно из «Test IT».

Дело в том, что Jenkins не распознает формат, в котором «Test IT» передает JSON - запрос через Webhooks:

так как механизм Jenkins не позволяет распарсить параметры, содержащие идентификаторы автотестов и тестовой среды.

То есть информация, которую «Test IT» передает в запросе, содержит:

• атрибуты текущего созданного TestRun (например, id, время старта, название, его статус),

•  коллекцию автотестов с их атрибутами (в том числе, уникальный идентификатор), выбранными для запуска, 

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

Jenkins в таком формате не воспринимает информацию, поскольку Job-ы запускаются путем отправки параметризированного REST API-запроса в другом формате.

Поэтому мы (работники Блока) разработали сервис JTIService (Jenkins-TestIt-Integration Service), который запускается из Windows. Сервис анализирует параметры, полученные от Webhooks, и вызывает параметризованный Job через API Jenkins. 

Функции сервиса JTIService:

• принимает запрос от «Test IT», 

• обрабатывает его, 

• на основе полученной информации осуществляет маршрутизацию в разрезе различных тестируемых проектов,

• отправляет запрос в Jenkins в формате API Jenkins на запуск требуемого Job,

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

 То есть в Jenkins создаются параметризированные Job-ы, которые в качестве параметров принимают от JTIService список идентификаторов автотестов и идентификатор тестовой среды. А Job в Jenkins запускает требуемые автотесты (параметр TestsTags) на определённой тестовой среде (параметр envName). (Напомним, для каждого проекта в «Test IT» используется свой Job, учитывающий специфику проекта.)

Приведем несколько примеров:

Для передачи информации о результатах прохождения автотестов система использует стандартные механизмы, например, «Allure Report». В него передается статус прохождения автотеста в «Test IT». Для этого у каждого объекта «Автотест» в «Test IT» имеется идентификатор тест-кейса, который ему соответствует. В каждом автотесте также указан этот же идентификатор.

Заключение

TMS-система «Test IT» благополучно функционирует в Блоке обеспечения качества и выпуска изменений ООО «РСХБ-Интех». В результате:

● Сократились сроки тестирования за счет того, что сократилось на 40% время на создание и обновление тестовой документации, а также в результате объединения ручных и автоматизированных тестов.

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

● Команда получила возможность прозрачно управлять тестированием и загрузкой сотрудников.

● Сократилось время на сбор отчетности по тестированию.