От банковского приложения пользователи ждут высокой безопасности и корректной работы в первую очередь. Ведь именно ему мы доверяем сокровенное — работу с нашими деньгами. Популярность мобильных банкингов, а с ними и нагрузка на приложения банков растёт. По оценкам Statista, в 2020 году число их пользователей во всём мире достигло 1,9 миллиардов человек, а к 2024 оно  вырастет до 2,5 миллиардов. Ещё один важный факт: банковские приложения работают с конфиденциальными данными, а значит, представляют собой мишень для кибератак. По данным отчёта “VMware Carbon Black”, только за три месяца 2020 года (февраль, март, апрель) число атак на финансовый сектор выросло на 238%. 

Очевидно, что банки крайне заинтересованы в стабильной и корректной работе своих сервисов. А как можно проверить своё приложение и избежать багов и угроз? Наш ответ: тестировать! Тестирование поможет обеспечить плавную и надёжную работу приложения и проверить защищённость его данных.

В этой статье мы расскажем, как тестируем банковские приложения и какие лучшие практики сформировали за 10 лет работы с крупными банками.

Почему тестировать банковские приложения сложно

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

Приложение интегрировано с множеством сторонних систем. Например, чтобы предзаполнить ваши данные для кредитной заявки, мобильное приложение, как правило, берёт данные из внутренних справочных систем банка. А чтобы сделать быстрый перевод денег через СБП, нужно сделать запрос к внешней базе данных на список всех банков получателя и подтвердить его данные. 

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

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

Приведём простой пример из проекта с банком Зенит: вот у нас есть экран подтверждения операции при помощи SMS. Код из SMS может подставляться полностью автоматически, в этом случае пользователь не совершает никаких действий, даже не подтверждает операцию. Это удобно для пользователя, но не удовлетворяет требованиям безопасности. 

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

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

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

Как тестируют банковские приложения

Мы не будем перечислять тут все возможные виды тестирования. Введём только пару понятий, которые понадобятся нам дальше. 

Итак, тестирование бывает:

• ручное — оно проводится без дополнительных программных средств, собственно, «вручную»;
• автоматизированное — в нём используются программные средства. 

И для тестирования банковского приложения не обойтись без обоих видов.

Когда нужно ручное тестирование

Тестирование банковского приложения (да и любого другого) всегда начинается с ручных проверок. Все фичи мы сперва проверяем руками и только после ручного тестирования можно переходить к автоматизации. Автоматизация проверок в приложении  в основном делается для так называемого регрессионного тестирования.

Регрессионное тестирование — это повторное выполнение тестов, которое помогает проверить, что ранее разработанное и протестированное программное обеспечение корректно работает после изменения.

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

Зачем нужно автоматизированное тестирование

Чем больше фич появляется в проекте (а в банковском приложении они разрастаются со скоростью снежного кома), тем больше сил уходит на ручное тестирование. А со временем оно становится и вовсе малореальным, ведь невозможно расширять команду тестировщиков бесконечно. Уже через шесть месяцев разработки тестировать всё вручную становится невозможно. В таблице ниже видно, как снижается доля тестов с увеличением срока проекта.

Постепенно проект достигнет точки, когда тестирование проводится по правилу Парето: вы проводите те 20% важных тестов, где высока вероятность найти 80% багов. Поэтому в долгосрочных проектах не обойтись без тестов, которые с меньшими затратами времени покроют бОльшую часть приложения — автоматизированных. 

Преимущества автотестов

• Они отлично справляются со сложной логикой и повторяющимися действиями, которых обычно много в банковских приложениях. 
• Способны обеспечить качество и скорость тестирования, которые невозможны при ручном тестировании. 
• Не зависят от численности команды QA, выполняются быстро и регулярно. Если добавить в команду одного человека, который будет писать автотесты, покрытие проекта тестами увеличится в разы. 

Но есть и некоторые нюансы. На сопровождение автотестов каждый год уходит около 30% времени, относительно потраченного на их написание. Арифметика такая: чтобы покрыть одну фичу автотестами, требуется 100 часов. Затем на сопровождение этого теста будет уходить 2,5 часа в месяц. Но это касается только  отлаженных фич. Если происходят серьезные изменения, автотесты придётся полностью актуализировать и затраты времени возрастут. 

Автотесты на Flutter — это отдельная история

Отдельно остановимся на автотестах для приложений, разработанных с использованием кроссплатформенной технологии Flutter, так как спрос на неё растёт. А так как технология относительно новая — 2017 года — процесс тестирования вызывает много вопросов. 

Мы реализовали на  Flutter проекты для двух крупных российских банков и вывели для себя некоторые правила. 

Flutter предоставляет возможность писать нативные автотесты на Dart и покрывает все необходимые виды тестов. Во Flutter доступны несколько видов автотестов и они решают разные задачи:

— UNIT-тесты. С их помощью проверяют конкретную часть системы, например, можно убедиться, что контроллер компонента устанавливает нужное состояние. Здесь не нужно эмулировать работы приложения. В Surf UNIT-тесты пишут разработчики, так как они больше вовлечены в описание внутренней логики приложения. 

А QA-инженеры пишут тесты двух других типов: виджет-тесты и E2E тесты. Они гораздо больше связаны с работой готового приложения и проверкой пользовательских сценариев.

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

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

— E2E (End-to-End) тесты проверяют работу приложения целиком и симуляцию пользовательских действий (свайпы, нажатие кнопок, заполнение форм) в реальной инфраструктуре с реальными сервисами, API и всем остальным. На Flutter такие тесты называются интеграционными. Такие тесты проводят перед каждой сборкой и перед релизом — времени они занимают немало, но позволяют тщательно проверить качество приложения.

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

Пентесты: проверка на безопасность

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

Пентест (penetration test, пенетрейшн тест) — это тестирование на проникновение и безопасность, анализ системы на наличие уязвимостей. Оценивает безопасность системы, моделируя атаку злоумышленников.

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

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

Инструменты тестирования

Для тестирования мы используем следующий набор инструментов: 

Dart+Gherkin — инструменты для нативных автотестов на Flutter;

Calabash (Ruby+Cucumber), RubyMine — инструменты для кроссплатформенных автотестов;

Jira — система для отслеживания багов и управления проектами;

Xray — многофункциональный инструмент для управления тестами, плагин для Jira;

Charles — HTTP прокси, благодаря которому тестировщики могут просматривать весь HTTP и SSL/HTTPS трафик между машиной и интернетом;

Figma —  векторный графический редактор и инструмент для создания прототипов;

Ряд систем аналитики (среди прочих — Firebase);

Android Debug Bridge (ADB) — универсальный инструмент командной строки, при помощи которого можно обмениваться данными с устройством;

Xcode — инструмент для создания iOS-приложений в целях тестирования;

Android Studio / Visual Studio Code — редактор кода нового уровня, оптимально подходящий для создания и отладки современных приложений.

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

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

Лучшие практики тестирования от Surf

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

Тестирование начинается с проверки технических требований и дизайна

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

Единая структура сценариев и чек-листов: все могут тестировать всё

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

У каждого из этих видов проверок есть своя структура, при этом она единая для всех сценариев или для всех чек-листов. Такой унифицированный подход помогает ускорить и усовершенствовать тестирование, а также не упустить ничего из важных моментов. А ещё так проще знакомить новых сотрудников с проектом. Даже когда специалист подключается на отдельных этапах проекта или переходит с проекта на проект, он понимает, что уже написано и как должна выглядеть реализация. 

Детально тестируем новые фичи 

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

Наводим лоск: финальное тестирование перед релизом

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

Подведём итоги

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

Чтобы тестирование проходило быстро, безболезненно и охватывало максимум, мы вывели для себя несколько лучших практик: 

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