Как выбрать и внедрить 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% время на создание и обновление тестовой документации, а также в результате объединения ручных и автоматизированных тестов.

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

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

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