Вступление
В этой статье расскажу о сервисе QA Admin, который разработал с нуля для нашей компании. Основная цель сервиса — упростить подготовку тестовых данных и сократить время, необходимое на тестирование.
Контекст
Мы занимаемся разработкой онлайн-банка и банковского мобильного приложения. У нас используется микросервисная архитектура: десятки команд работают с сотнями различных сервисов, включая тестовые. Например, процессинг, над которым одновременно трудятся несколько команд. Кроме того, мы используем сотни Kafka-топиков. Все эти элементы задействованы в процессе тестирования, в том числе для генерации тестовых данных.
В ходе тестирования каждый раз требуется создавать тестовых пользователей и различные данные: типы счетов, заявки, выписки, карты, пополнения, покупки, переводы, кешбэки, рассрочки, нотификации, тарифы, подписки и многое другое. Для этого нужно работать с множеством сервисов, иногда до нескольких десятков. При этом приходится "таскать" за собой идентификаторы вроде user_id, account_id, phone_number и т.д.
Если нужно создать двух или трёх тестовых пользователей, задача становится ещё сложнее. Например, требуется:
создать пользователя,
выбрать кешбэк,
добавить несколько покупок и пополнений,
оформить рассрочку,
активировать подписку,
прокрутить бизнес-дни до выписки,
в конце закрыть счёт.
Для выполнения этих действий нужно задействовать несколько сервисов и команд. Если QA-инженер знает, куда идти, это может занять 30–50 минут. Но если нет — задача легко растягивается на целый день. Кроме того, вызовы gRPC-методов или HTTP-ручек часто требуют заполнения множества полей, а для этого нужно знать, что указывать.
Проблемы
Типичная ситуация, знакомая многим компаниям, где куча команд и в каждой по несколько микросервисов. Утро понедельника, Вася первый день вышел на работу. Ему дают задачку: проверить, как в мобильном приложении отображается новая фича — новый формат даты для выписки.
Вася уже всё настроил: VPN подключил, тестовую сборку скачал, сниффер запустил — молодец, подготовился. Открывает приложение, но тут возникает вопрос: а где взять тестовый аккаунт? Вася идёт к коллеге Ивану из своей команды и спрашивает:
— Где мне можно взять тестовый аккаунт?
Иван, конечно, сразу кидает ссылку на swagger тестовой тулзы, где можно сгенерировать аккаунт. Вася генерирует аккаунт, заходит в приложение… и видит, что на аккаунте нет ни одной выписки.
Снова к Ивану:
— Как мне сгенерировать выписку?
Иван пожимает плечами:
— С этим беда, я сам не знаю, это вообще другая команда делает. Но у меня где-то завалялся аккаунт с выпиской трёхмесячной давности.
Иван делится аккаунтом, но когда Вася логинится, приложение радостно встречает его надписью: Something went wrong. В третий раз Вася возвращается к Ивану, и выясняется, что аккаунт давно сломан. Иван, вздохнув, отправляет Васю в чат команды, которая отвечает за выписки.
Там Васе отвечают через пару часов:
— У нас сейчас супергорящая фича, генерация выписок — дело непростое, подожди ещё пару часов.
Спустя весь день мучений Вася, наконец, получает нужный аккаунт и просто смотрит, как отображается новая дата. День угроблен, куча времени потрачена на переписки и "походы к Ивану", а задача-то изначально была "на пять минут, вошли и вышли".
Но это ещё не конец. Через неделю появляется новая задача: проверить отображение долга по счёту. Для этого нужно сгенерировать две выписки. Вася, "со слезами на глазах", снова идёт в команду, которая отвечает за выписки. Там ему говорят:
— У нас тестовый стенд сломался, подожди, пока починим.
И вот Вася опять в положении "попрошайки": постоянно вымаливает аккаунты, а теперь ещё и надоедает другой команде, пингует их в духе:
— А вы уже починили? А вы про меня не забыли?
Но это ещё не всё. Через неделю к Васе прибегает дизайнер и срочно просит тестовый аккаунт с кешбэками на следующий месяц. Нужно проверить какое-то очень важное отображение в мобильном приложении. Вася, как человек ответственный, конечно, хочет помочь, но пока сам не знает как.
Идёт в чат команды, которая занимается кешбэками, по мнению Васи, но оказывается, что кешбэками заведует другая команда. Вася, метаясь по чатам, ищет тех, кто может помочь настроить кешбэки на следующий месяц. После нескольких попыток и двух часов времени он, наконец, получает тестовый аккаунт. Для этого пришлось сделать запрос к gRPC-сервису и отправить хитрое сообщение в Kafka. Аккаунт передан дизайнеру.
И вот тут Васю посещает мысль:
"А не отправить ли дизайнера самому бегать по чатам?"
Но разница всё-таки есть. Если Вася, хоть и с трудом, но в контексте всех тестовых процессов, то дизайнеру, который далёк от технических деталей, на это могло бы уйти целый день.
А теперь представим, что происходит, если начинается регресс. Тут уже одного-двух аккаунтов недостаточно, нужны десятки аккаунтов в разных состояниях. И это уже не смешно. Вася вынужден «перебиваться» старыми аккаунтами из «запаса», а иногда и просить у других команд. Ситуация превращается в настоящий хаос, где все друг у друга что‑то выпрашивают, лишь бы как‑то дотянуть до конца тестов.
Эта история отлично иллюстрирует, что было до разработки тестового сервиса QA Admin. И таких «Вась» у нас было много. Но это не проблема Васи, это недоработка тестовых процессов и отсутствие нормального централизованного решения для работы с тестовыми данными. Ну и дух стартапа в придачу: времени на выстраивание и отладку таких процессов ни у кого особо нет, всё растёт и развивается слишком быстро, уследить за всем невозможно, да и знать всё наперёд — нереально. А иногда, особенно в рамках интеграционного тестирования, волей-неволей приходится взаимодействовать с другими командами
Делаем выводы:
Сложность для смежных специалистов. Опции подготовки тестовых данных часто ограничены только QA-инженерами, которые хотя бы понимают, какие сервисы и данные им нужны. Для других специалистов (разработчиков, системных и бизнес-аналитиков, продукт-менеджеров, дизайнеров) самостоятельная генерация данных практически невозможна. Поэтому они вынуждены обращаться к QA-инженерам, отвлекая их от других задач;
Асинхронная коммуникация между командами. QA-инженеры одной команды нередко просят коллег из другой команды помочь с генерацией пользователей или добавлением операций. Это приводит к задержкам, так как коммуникация обычно происходит асинхронно, а ответы могут занимать от нескольких часов до нескольких дней. Иногда запросы остаются без ответа. Более того, инженеры не всегда четко формулируют запрос, что приводит к длительным уточнениям и дополнительным временным затратам;
Регрессионное тестирование. Во время регрессии нагрузка возрастает многократно. Требуется создать десятки, а иногда и сотни тестовых пользователей с разными состояниями. Это приводит к огромным временным затратам и снижению качества тестирования из-за невозможности своевременной подготовки данных.
Всё это приводит к:
потере времени;
лишним коммуникациям;
ухудшению качества продукта, так как иногда просто не хватает тестовых данных для проверки всех сценариев.
Решение
Сервис QA Admin стал решением этих проблем. Сервис интегрирован с 50+ различными системами и предоставляет удобный UI для генерации тестовых данных. Это дало несколько важных преимуществ:
Ускорение генерации данных. Если раньше создание тестовых пользователей занимало от десятков минут до нескольких дней, теперь это занимает считанные секунды. Большинство операций можно выполнить в пределах одной минуты.
Автономность. QA Admin позволяет генерировать данные без необходимости взаимодействия с другими командами. Например, команда процессинга может легко получить нужный аккаунт одним кликом, не углубляясь в детали работы других команд.
Доступность для всех специалистов. Теперь разработчики, системные и бизнес-аналитики, продукт-менеджеры и дизайнеры могут самостоятельно генерировать данные. Это освобождает QA-инженеров от лишней нагрузки и экономит общее время.
Важно не путать QA Admin с бэкофисом. Это принципиально разные инструменты:
Бэкофис доступен на продакшене, требует авторизации и соблюдения прав доступа.
QA Admin — исключительно тестовый сервис, который не используется на продакшене. Он позволяет выполнять «незаконные» операции (например, пополнения на миллионы долларов) для тестирования.
Архитектура
Архитектура сервиса QA Admin максимально проста и состоит из двух основных частей:
Бэкенд. Серверная часть написана на Python с использованием популярного стека:
FastAPI — для создания REST API;
Pydantic — для работы с валидацией данных;
SQLAlchemy — для взаимодействия с базой данных;
Uvicorn — для запуска сервера.
Выбор данного стека очевиден благодаря его простоте, скорости разработки и удобству. Основная цель при создании тестового сервиса — сделать всё быстро и качественно, чтобы инструмент работал стабильно и лишний раз не отсвечивал. Производительность, как правило, не является ключевым критерием для таких решений. Тем не менее, FastAPI достаточно быстрый, поэтому по этому показателю он тоже отлично справляется с задачей.
Роль бэкенда. Бэкенд выполняет роль своеобразного GATEWAY между внешними сервисами и пользовательским интерфейсом. Однако назвать его полноценным GATEWAY нельзя, поскольку он имеет собственную базу данных (а классический GATEWAY, как правило, базу данных не использует).
Интеграция с другими сервисами осуществляется:
в основном через gRPC протокол,
частично через Kafka (например, для отправки сообщений в топики),
реже через HTTP.
Интеграция с тестовыми сервисами. Некоторые команды предоставляют собственные тестовые сервисы для генерации специфичных данных. Бэкенд QA Admin интегрируется с ними, что позволяет использовать их функциональность для упрощения генерации сложных тестовых данных.Фронтенд. Фронтенд реализован на React с использованием следующих инструментов:
Redux — для управления состоянием,
Material-UI (MUI) — для создания современного, удобного и масштабируемого интерфейса.
Этот стек позволяет создать красивый и функциональный UI, который также легко адаптируется и масштабируется при необходимости.
Функционал
Описывать весь функционал сервиса займет много времени, к тому же он содержит множество продуктовых нюансов, которые могут быть не совсем понятны читателям. Поэтому давайте кратко пробежимся по основным возможностям.
Создание различных типов аккаунтов
После создания аккаунта все связанные данные автоматически подтягиваются во всю админку
Далее все действия выполняются для выбранного пользователя, при этом сервис автоматически подставляет необходимые данные, такие как user_id, account_id и прочее. Это избавляет от необходимости вручную передавать множество параметров. Если требуется получить дополнительные данные, админка сама отправит запрос в нужный сервис, получит необходимую информацию и подставит её в соответствующий запрос.
Состояние клиента сохраняется (персистируется), что означает: даже при перезагрузке страницы все данные останутся доступными. Для очистки состояния достаточно нажать на иконку корзины в правом верхнем углу, после чего оно будет сброшено.
Также доступна возможность установки текущего пользователя. Если у вас уже есть тестовый пользователь, его можно задать по phone_number, user_id или account_id в QA Admin. После этого все дальнейшие действия будут выполняться для этого пользователя. Эта функция особенно полезна, если известен только user_id, но требуется узнать, например, phone_number. Установив пользователя, админка автоматически подтянет все связанные данные.
Операции
Сервис поддерживает генерацию различных типов операций: покупки, комиссии, переводы, пополнения, снятие наличных, возвраты и многое другое. На текущий момент доступно 37 видов операций, охватывающих практически все сценарии тестирования.
После создания операции они отображаются в виде списка, с которым можно выполнять дальнейшие действия.
Выписки
Процесс генерации выписок у нас достаточно сложный и включает взаимодействие сразу с несколькими сервисами. Выполнять его вручную довольно трудоемко, однако в QA Admin всё сводится к нажатию одной кнопки.
Кстати, этот функционал является одним из самых популярных после создания операций, что неудивительно, учитывая его сложность.
Сохранение тестовых пользователей
В QA Admin доступен функционал Users Store, который позволяет сохранять тестовых пользователей для их последующего переиспользования.
Если вы работаете с большим количеством пользователей и часто переключаетесь между ними, либо не хотите каждый раз создавать новых, Users Store отличное решение, как минимум избавляет от необходимости хранить пользователей "в блокноте". Можно сохранить пользователей в хранилище и быстро переключаться между ними при необходимости.
Кроме того, пользователями из Users Store можно делиться с коллегами, предоставляя им доступ к вашему хранилищу. Это особенно полезно, если есть общий пул тестовых пользователей, например, для команды или регрессионного тестирования, чтобы избежать дублирования. Синхронизация осуществляется через уникальный client_id или путем сканирования QR-кода.
QR code
Некоторые данные можно копировать или открывать с помощью сканирования QR-кода. Это особенно удобно при тестировании диплинков. В QA Admin можно собрать нужный диплинк прямо в интерфейсе.
После этого есть два варианта:
Открыть админку на мобильном устройстве и воспользоваться кнопкой "Open deep link", чтобы сразу перейти по диплинку.
Сканировать QR-код, в который зашит диплинк. Это можно сделать с помощью камеры телефона, и диплинк автоматически откроется в мобильном приложении.
Дополнительно диплинк можно сохранить в deep links store, чтобы использовать его позже. Все диплинки синхронизируются вместе с сохранёнными пользователями в users store, через client_id.
Widgets
Весь функционал разделён на виджеты, каждый из которых представляет собой стандартизированный view, которым можно управлять.
Каждый виджет можно скрыть. К каждому виджету прилагается документация с гайдами, объясняющими, как работать с виджетом и какие действия с ним можно выполнять.
Так выглядят настройки виджета
Как уже упоминалось, каждый виджет можно скрыть, если он не нужен. Документацию можно также скрыть, если ты уже знаком с функционалом. Также можно скрыть блок Actions или изменить его положение — например, переместить его в начало или в конец виджета. Если операций много и виджет становится громоздким, можно переместить блок Actions наверх для удобства.
Все настройки виджетов персистентны, то есть если мы настроили виджеты под себя, после перезагрузки страницы все настройки сохранятся.
Other
Это далеко не весь функционал, а лишь его небольшая часть — примерно 5-10%. В целом, весь функционал позволяет сгенерировать практически любого пользователя через понятный и удобный UI, без необходимости заходить в множество различных сервисов, запоминать их настройки и контракты.
Кроме того, больше не нужно использовать неудобные списки пользователей в Confluence или других местах, которые быстро устаревают и перестают обновляться. В users store всегда будут актуальные пользователи, и при этом синхронизация между коллегами гарантирует, что данные будут всегда актуальны.
Короче, QA Admin предоставляет множество полезных функций, которые значительно упрощают и ускоряют процесс тестирования.
Заключение
Сервис QA Admin не является гениальным или незаменимым инструментом. Если его убрать, тестирование продолжится, но вопрос в том, с какими усилиями, трудозатратами и временными затратами. Основная задача сервиса — сэкономить как можно больше времени на подготовке тестовых данных и упростить этот процесс. Также важно сделать процесс подготовки данных доступным для всех специалистов, даже тех, кто далёк от технических деталей, но всё равно нуждается в тестовых пользователях.
Самое удивительное, что основа сервиса QA Admin была написана за одни выходные, то есть достаточно быстро. При этом сервис уже функционирует в течение 9 месяцев, почти год, и за это время не было негативных отзывов от коллег — только положительные. Что касается временных затрат на разработку и поддержку QA Admin, они минимальны. Иногда сервис работает автономно по две-три недели без каких-либо проблем. По просьбе коллег добавляю новый функционал, что обычно занимает от нескольких минут до одного-двух рабочих дней.
Однако стоит отметить, что для быстрой работы с сервисом нужно хорошо разбираться в серверной и фронтенд-разработке. Соответственно, для обычного QA инженера порог входа может быть достаточно высоким.
