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

Статья опубликована в блоге компании РСХБ

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональная область

Требования

Создание, хранение 

и ведение тестовых кейсов

Создание тестовой модели в зависимости от выделенных функциональных областей.

Разделение по проектам / функциональным областям / тестируемому ПО.

Версионность описания кейсов (по патчам / релизам).

Описание в формате rtf / doc. С форматированием и картинками.

Пошаговое описание кейса.

Хранение ожидаемого результата шага и / или кейса.

Возможность создания пользовательских полей – атрибутов тестовых сценариев.

Группировка кейсов внутри проекта по функциональной области тестирования.

Экспорт / импорт кейсов в xml (xls, doc).

Хранение истории запуска теста.

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

Добавление предусловий и тестовых данных, code block и изображений.

Общие шаги

Хранение тест-кейсов и возможность написания сложных запросов для их поиска, сохранения запросов и передачи данных запросов пользователям системы.



Планирование 

и выполнение тестирования

Планирование тестирования и назначения тест-кейсов ответственным исполнителям.

Формирование списков тестов для тест-плана.

Указание очередности запуска тестов.

Хранение истории запусков (прохождений) тест-плана.

Время прохождения теста.

Формирование отчетов по результатам тест-плана.

Возможность отправки отчетов на почту.

Возможность печати тест-планов.

Возможность повторного прогона только что упавших тестов.

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

Автоматическая балансировка тест-кейсов между ответственными, в зависимости от нагрузки.

Возможность выбора окружения запуска теста.

Фиксация и хранение результатов тестирования.



Отчетность

Оптимизация процесса тестирования за счет измерения метрик тестирования (планируемое время прохождения тест-кейса, чек-листа).

Отчеты по тест-планам, по статусам прохождения тестов, по кол-ву найденных ошибок, по распределению нагрузки на специалистов, по актуальности ручных и автоматизированных тестов и др.).

Формирование отчетов по планам тестирования.

Формирование отчетов по проектам.

Обеспечение быстрого доступа к данным для планирования, подготовки, проведения тестирования информационных систем (далее – ИС) и обработки результатов тестирования ИС.



Взаимодействие API

Отслеживание покрытия требований тестовыми сценариями и автотестами.

Связь автоматизированных тестов с ручными тест-кейсами в системе управления тестированием.

Получение списка кейсов в тест-плане ( testrun ).

Получение реквизитов кейса.

Установка результата прогона теста.

Сохранение произвольных данных в результате прогона теста.

Добавление кейсов в тест-план (testrun).

Получение заданий на запуск автоматизированных тестов.

Управление запусками автоматизированных тестов.

Присвоение тест-кейсам результатов запусков автоматизированных тестов.

Добавление документов (вложений) к результатам автоматизированных тестов.

Интеграция с Jira через публичный API ПО. Двухсторонняя синхронизация связей между артефактами тестирования, дефектами и требованиями.

Интеграция с средствами запуска автотестов (посредством Public API).



Интеграция с внешними системами

Jira. Регистрация дефектов.

Jira. Отслеживание статуса исправления дефекта.

Почтовый сервер. Отправка почты с вложениями.



Система доступа / Ролевая модель

Системный уровень, 3 роли: Администратор, Руководитель проекта, Пользователь. Уровень проекта: Полный доступ, Запись, Выполнение, Чтение.

Разграничение уровней доступа по проектам.

Массовое редактирование выбранных реквизитов кейсов.



Иное

Возможность восстановления данных.



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

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

Общая информация

Test IT

TestRail

Adaptavist

Microfocus ALM

Страна производитель

РФ

Германия

Англия

Англия

Фиксированная валюта для продаж

RUB

USD

USD

USD

Установка on premise

Да

Да

Да

Да

Перемещение тест-кейсов из проекта в проект и из секции в секцию + drag and drop

Да

Да

Да

Да

Общие шаги

Да

Нет

Да

Да

Автотесты

Да

Нет

Да

Да

Конфигурации

Да

Да

Нет

Да

Импорт данных из другой TMS

Да

Да

Нет

Да

CI / CD

Да

Да

Да

Да

Экспорт отчетов

Да

Да

Да

Да

Интеграция с Jira

Да

Да

Да

Да

API

Да

Да

Да

Да

Современный UI

Да

Нет

Да

Да

История версий тест-кейсов

Да

Нет

Да

Да

Webhooks

Да

Нет

Нет

Да

Пользовательские атрибуты

Да

Да

Нет

Нет

Массовое изменение пользовательских атрибутов и тегов

Да

Да

Нет

Нет

Время прохождения теста

Нет

Да

Да

Нет

Интеграция с AD/LDAP

Да

Да

Нет

Да

Управление ролями и разрешениями

Да

Да

Нет

Да

Нотификации и комментарии

Да

Нет

Да

Да

Авторизация через OpenID connect

Да

Нет

Нет

Нет

Массовые действия с тестами

Да

Да

Да

Нет

Автобалансировка при назначении исполнителей на тесты

Да

Нет

Нет

Нет

Результаты для каждого шага

Да

Да

Да

Да

Багтрекер

Нет

Нет

Да

Да

Расширенный поиск

Да

Да

Да

Да

Внутренний чат и уведомления

Да

Да

Нет

Да

Оповещения во внешнюю систему

Да

Да

Нет

Да

Элементы вовлечения

Да

Нет

Нет

Нет

Автобалансировщик нагрузки

Да

Нет

Нет

Нет

Метрики и отчёты

Экспорт отчетов

Да

Да

Да

Да

Метрики среднего времени прохождения и падения автотестов

Да

Нет

Да

Да

Отчеты по автоматизации

Да

Нет

Нет

Да

Отчеты по статусу

Да

Да

Да

Да

Отчеты по приоритету

Да

Да

Да

Да

Распределение результатов по тест-планам

Да

Да

Да

Да

Отчет по тест-планам со статистикой прохождения

Да

Да

Да

Да

Статистика по сотрудникам

Да

Да

Нет

Да


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

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

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

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