Важно, но не видно глазу: как и зачем мы тестируем банковские приложения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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