Привет, Хабр! Всем известно, что у тестировщиков в жизни много трудностей. И мы, команда QA Департамента общих прикладных сервисов (ДОПС) Сбера, знаем об этом не понаслышке, так как тестируем релизы сервисов Platform V — цифровой облачной платформы СберТеха (более 70 продуктов для быстрого создания и легкого масштабирования приложений любой сложности). Да‑да, именно на Platform V Сбер совершил свою цифровую трансформацию!

Релизы поставляют в банк из СберТеха. Всё бы ничего, пришли изменения — тестируй. Но основная сложность заключается в том, что у платформы десятки продуктов, из‑за чего работа усложняется в разы.

Что тут можно придумать и как облегчить и без того насыщенную жизнь тестировщиков? При проверке новых релизов мы используем все классические виды тестирования: нагрузочное, функциональное и их автоматизацию, деструктивное, тесты с потребителями. Но нам захотелось большего! «Как повысить скорость тестирования и снизить трудозатраты на это?», — такой вопрос засел у нас в головах. И вот, спустя какое‑то время, у нас родилась идея — разработать Синтетическое приложение Platform V.

Что есть Синтетика?

Определение из документации гласит, что Синтетическое приложение — это «набор инструментов для тестирования платформенных сервисов, реализующий интеграционные бизнес‑сценарии, имитирующие реального потребителя». На деле же, наша Синтетика — это небольшое приложение, развернутое в облаке. Тут все по классике: OpenShift для контейнеризации, Egress/Ingress для организации трафика и все остальные необходимые сущности.

Как она тестирует?

Для проверки сервисов мы разработали большой интеграционный сценарий, в который входят базовые банковские операции: открытие счета, перевод денежных средств, выписки, платежи и другие. Синтетические сценарии максимально эмулируют запросы потребителей и задействуют сразу несколько продуктов платформы.

В рамках выполнения запроса мы обращаемся к тем или иным сервисам Platform V, которые уже успели интегрировать с нашим приложением. К примеру, в сценарии «создание счёта» Синтетическое приложение за один запрос вызывает порядка 10 сервисов, аналогично тому, как это сделали бы реальные потребители платформы.

Вот некоторые из задействованных сервисов:

• DataSpace — сервис для работы с данными (аналог Hibernate).

• Audit — сервис для регистрации и долговременного хранения событий информационной безопасности.

• One‑Time‑Token — инструмент для контроля доступа.

• Archiving — сервис архивирования и передачи данных в аналитическую платформу.

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

В чём плюсы такого подхода?

Среди достоинств нашей Синтетики можно выделить следующие:

1. Атомарность. Множество сервисов могут существовать только в рамках продуктов потребителей. Подобные компоненты нельзя установить без использующего их приложения — они не могут существовать атомарно. Такие клиентские модули зачастую сложно протестировать «руками». И наше приложение — это оптимальное решение для их проверки.

2. Новый слой тестирования. Так как мы так же, как и реальные потребители, раскатываемся в своем пространстве, то у нас есть собственный CI/CD процесс, в котором мы можем отлавливать возникающие инсталляционные дефекты.

3. Интеграция. Кроме всего вышеперечисленного, мы проводим проверки непосредственно межсервисного взаимодействия: модуль авторизации, сервисы репликации данных.

Но не всё так просто…

На самом деле, раздел про проблемы является для нас самым болезненным:) Мы одни из первых получаем обновления и подключаем новые сервисы платформы в качестве потребителя. То есть все ошибки, недочёты, опечатки мы собираем в полном объёме. Это и проблемы с документацией, и инсталляционные проблемы, и разница в окружениях.

За время работы над Синтетикой курьезных ситуаций случалось достаточно много. Но, пожалуй, один из самых забавных случаев, с которым мы столкнулись — это ответ на вопрос: «А почему все‑таки сервис не работает?». «Сейчас проблема в том, что вы подключили все, что указано в документации», — невозмутимо ответили нам в сопровождении.

Но, с другой‑то стороны, каждая проблема — это вызов. И так как у нас их много, мы быстро учимся. За прошедшие полтора годы мы превратились из обычных Java‑разработчиков в Java‑разработчиков, разбирающихся в CI/CD процессах, процессах сертификации и безопасности, администрировании инфраструктуры и, что немаловажно, закаливших свою нервную систему!

Ну а главное, что помогает переносить все невзгоды, — вера, что мы можем сделать продукт лучше. И, не побоимся этого сказать, — понимание того, что мы стоим на страже потребителя.

Промежуточные итоги

Итак, в сухом же остатке за прошедшие полтора года жизни к нашему приложению было подключено более 80% сервисов Platform V. Что привело к:

1. Значительному уменьшению времени тестирования на потребителях. Для интеграционного тестирования оно снизилось вдвое, а для Smoke тестирования в 4 раза.

2. Расширению покрытия, включая интеграционный слой и CI/CD процессы.

3. Упрощению процесса установки непосредственным потребителем сервиса.

На будущее мы себе поставили цель охватить все 100% сервисов платформы, и разработать ряд прикладных шаблонов, чтобы подключение новых сервисов занимало минимум времени. Раз уж мы первыми «трогаем продукт», то мы мечтаем облегчить этот путь будущим потребителям.