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