Как мы тестируем криптовалютные операции в Wirex

Wirex — британская финтех-компания с R&D-центром в Киеве. Наши разработчики создают продукт, которым пользуются более 4 млн пользователей по всему миру. Поскольку Wirex объединяет традиционные деньги и криптовалюты в одном приложении, для нас крайне важно обеспечить бесперебойный доступ клиентов к своим деньгам, и быть уверенными, что продукт работает исправно.

Сейчас наш R&D-центр находится в поисках QA-специалиста, который будет заниматься тестированием функционала нашего приложения. И если вы хотите присоединиться к нашей команде, специально для вас Head of QA Роман Макитренко написал статью на DOU.ua, в которой рассказывает об особенностях тестирования криптовалютных операций, а также подходах, которые мы используем в Wirex при проверке функционала нашего продукта. Текст публикуется с разрешения редакции.

Роман Макитренко: Как найти баланс между потерями из-за ошибки и быстрой реализацией функционала

Роман Макитренко, Head of QA Wirex

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

Поэтому существует ряд критериев, которые нужно учитывать QA-специалистам при работе с финтех-продуктом:

• Безопасность. Финтех-приложения используют и хранят конфиденциальные данные, включая личную, финансовую и банковскую информацию. Нужно помнить, что хакеры могут попытаться получить доступ к этим сведениям.
• Защита данных. В мире финансовых технологий информация часто переходит из рук в руки, поэтому защита важных данных и управление ими — ключевой момент на этапе тестирования продукта. Бреши в этой сфере могут быть причиной судебных исков и проблем с соблюдением регуляторных требований, в результате чего клиенты могут потерять доверие к компании.
• Соблюдение нормативных требований. Лицензированные фи организации должны соблюдать строгий набор правил и положений регуляторов тех стран, в которых они работают. Эти законы постоянно эволюционируют, поэтому тестирование функционала должно меняться вместе с ними. Проблемы с комплаенсом могут спровоцировать ограничение на выполнение некоторых финансовых операций или полностью заблокировать работу приложения в некоторых странах или регионах.
• Функциональное тестирование — важный этап любого сценария тестирования. Этот процесс гарантирует, что продукт соответствует всем необходимым требованиям для эффективной работы. Поскольку программное обеспечение финтех-продукта предполагает обмен конфиденциальными данными и информацией, тестировщики должны изучить все возможные риски, события, факторы стресса и взаимодействия с другими приложениями и компонентами системы. В случае, если какой-то функционал окажется недоступным или неактивным, клиенты могут выбрать продукт конкурентов, вследствии чего компания может недополучить прибыль от операционной деятельности. Также важно понимать, что проблемы с сервисами третьих сторон нужно решать, как свои собственные, поскольку пользователям все равно на чьей стороне существуют проблемы, они будут жаловаться на ваше приложение.
• UX: в основе качества продукта лежит то, насколько он удобен и прост в использовании. Основной приоритет финтех-продукта — клиентский опыт, и QA должен гарантировать, что продукт понятен и легок в использовании для неспециалистов. Проблемы с UX обычно имеют прямое финансовое влияние на компанию, поскольку пользователь может выбрать приложение конкурентов.
• Производительность — важно убедиться, что платформа и сервисы продолжают работать в часы пик, вне зависимости от нагрузки. Зачастую такие проблемы не приходят в одиночку и, как правило, объединяются с проблемами UX.

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

Также, прежде чем приступить к тестированию, убедитесь, что вы знаете, где взять тестовые криптовалюты, поскольку Bitcoin в тестнете и майннете — это все же две разные валюты, с абсолютно разными свойствами и скоростью работы.

Базовый функционал криптовалютного финтех-приложения

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

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

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

Безусловно, для работы в приложении пользователю потребуются деньги. Это может быть Welcome бонус или любой другой способ, который обеспечивает пополнение баланса в системе.

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

Давайте рассмотрим каждый из этих функционалов более подробно.

Регистрация криптовалютного аккаунта

Для регистрации криптоаккаунта мы используем системные аккаунты (master accounts), который принадлежит компании, и дополнительный (sub-account), который принадлежит пользователю.

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

Давайте проверим, как приложение работает в динамике.

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

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

Пополнение криптовалютного аккаунта

Чтобы пользоваться приложением, у юзера должны быть деньги на балансе в системе. Один из вариантов — это внешний или внутренний перевод криптовалюты на адрес пользователя в системе (receive flow).

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

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

Округление суммы

Один из самых распространенных кейсов для проверки в финтех-продукте, особенно который работает с криптовалютами — сложности с округлениями, длинными числами, множеством знаков после «,» в десятичных значениях. Например, пользователь пересылает в систему 1.999998, но в результате округления/преобразования типов имеет возможность отправить за пределы системы 1.999999.

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

Подтверждение транзакции

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

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

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

Операции с обменом криптовалют

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

Этот процесс выглядит следующим образом:​

• Выбор валюты для покупки и продажи.
• Ввод данных, — сумма для обмена.
• Следующий шаг — подтверждение операции.
• И, наконец, система должна показать оповещение об успешно проведенной операции.

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

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

Лимиты. Как и следовало ожидать, каждая операция имеет определенные ограничения в том числе, которые требуются со стороны законодательства для лицензированных финтех компаний. Существуют различия между верхним и нижним границами для конкретной пары валют. Например, система не работает с транзакциями меньше в эквиваленте одного цента или больше 1000 BTC, поскольку это может привести к существенному риску. Или же не выполняет определенное число операций подряд, поскольку это расценивается как подозрительная активность. Это может быть любое другое техническое, регуляторное ограничение. Такие кейсы крайне важны для проверки.

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

Важно предусмотреть различные сценарии развития действий — например, обновления или проблемы на стороне криптовалютной биржи. Что тогда система должна делать с обменными ценами на активы — продолжать операции по последним биржевым курсам — довольно рисково, прекращать торговлю — тоже. Все эти ситуации следует учитывать при тестировании своего продукта.

Также важно контролировать баланс на аккаунтах системы внутри криптобирж, потому что в случае недостачи средств, система должна сообщить о проблеме. То же должно происходить, если юзер продал криптовалюту системе, но не конвертировал деньги на бирже.

Важно контролировать обновление курсов валют через короткий промежуток времени, поскольку из-за волатильности цифровых активов их цена может существенно отличаться на протяжении одного дня, и пользователь может сделать заявку, но не нажать кнопку «подтвердить» в ожидании лучшего курса. Такой сценарий также необходимо учитывать при тестировании криптовалютного финтех-продукта.

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

Например, в системе 10 криптовалют, и пользователи могут обменивать активы на каждую из валют из этого списка. Сколько тогда цен у нас в системе? Ответ — 45

Число сочетаний обозначается Cnm и вычисляется по формуле:

где n=10 — количество валют, m=2 — количество валют в паре.

И это только обмен между валютами. Для каждой валютной пары есть две цены — покупки и продажи, выходит 90 цен. Минимум такое количество цен мы имеем с биржи, учитывая кроссвалютный курс. Выходит 180. Цены с комиссией компании и без нее. В итоге в сумме получится более 500 цен. А теперь посчитайте сколько займет времени ручной регресс.

Вывод денег за пределы системы

В этом кейсе флоу следующий:

• Клиент выбирает валюту для отправки.
• Вводит значение — сумму перевода.
• Подтверждает транзакцию.
• Система публикует транзакцию на блокчейне.

Что в это время происходит на бэкенде?

Система проверяет баланс на аккаунте юзера. Затем система проводит расчет комиссии. Мы помним, что каждая транзакция в блокчейне должна подтверждаться майнерами. Это значит, что такие переводы требуют комиссии для майнеров.

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

При выводе денег за пределы системы необходимо проверить существующие лимиты.

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

Как лучше тестировать приложение: вручную или автоматически?

Я уверен, что невозможно протестировать регрессию в ручном режиме, если у вас более 10 валют, 2–3 — еще возможно, поэтому самое время автоматизировать тестирование.

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

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

В Wirex мы реализовываем автоматизацию как со стороны бэкенда, так и фронтенда — на iOS, Android, веб-приложении и сайте.

Со своей стороны, разработчики внедряют автоматизацию на всех уровнях: от модульного тестирования до интеграционного. Основное внимание девелоперов уделяется техническому поведению системы, в то время как QA больше сосредоточены на поведении бизнеса. Означает ли это, что QA не автоматизируют сервисы? Нет, мы это тоже делаем. Так же, как и разработчики — тестировщики тоже автоматизируют сервисы с точки зрения бизнеса, так как у каждого сервиса есть своя бизнес-цель. Мы работаем как команда, в которой разработчики используют код QA и наоборот.

Кто занимается разработкой автотестов в команде QA? Все, в нашей команде нет ручного или автоматического QA, мы все QA полного стека. Когда я говорю «все», я имею в виду каждого члена команды, включая меня. Мы поддерживаем и помогаем друг другу учиться и совершенствоваться в ручном и автоматическом тестировании.