Даже правильно выбранная 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». Изучили их возможности и занесли в таблицу:

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

Таким образом, мы выбирали между «Test IT» и «Microfocus ALM». Но поскольку разница в цене была существенной, мы выбрали «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% время на создание и обновление тестовой документации, а также в результате объединения ручных и автоматизированных тестов.
• Повысилось качество тестирования за счет автоматизации внедрения лучших практик тестирования и внедрения общей стратегии поддержки качества для различных методологий разработки.
• Команда получила возможность прозрачно управлять тестированиеми загрузкой сотрудников.
• Сократилось время на сбор отчетности по тестированию.