Тестирование банковских приложений: как ловят баги, которых не видно

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

почему возникают ошибки, которые не видны на демонстрации приложения

Пятница, 18:47. Клиент банка переводит контрагенту 340 000 рублей за партию товара. Приложение показывает крутящийся индикатор пять секунд, потом ошибку соединения. Клиент жмёт «повторить». Через минуту деньги списываются дважды — интернет на самом деле не прерывался, просто ответ сервера пришёл на секунду позже таймаута.

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

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

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

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

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

функциональные и нагрузочные тесты

Функциональные тесты проверяют, что каждый сценарий — вход по биометрии, перевод, оплата по QR, push о зачислении — работает так, как задумано, включая нетипичные пути: обрыв связи в момент подтверждения, повторное нажатие кнопки, смену SIM во время сессии. Нагрузочные тесты имитируют пиковую нагрузку: утро понедельника, день зарплаты, распродажу у партнёра — момент, когда в приложение одновременно заходит в разы больше пользователей, чем обычно.

security и приёмочные тесты

Security-тестирование ищет способы обойти авторизацию, перехватить токен сессии или получить доступ к чужому счёту через подмену параметров запроса. Для приложений с персональными данными клиентов это тестирование напрямую связано с требованиями 152-ФЗ о защите персональных данных: проверяется не только код, но и то, как хранятся и передаются логи, где лежат резервные копии и кто имеет к ним доступ. Приёмочные тесты (UAT) — последний контур: их проходят реальные сотрудники заказчика на реальных, а не выдуманных сценариях бизнеса, и именно здесь всплывают расхождения между тем, что написали в техническом задании, и тем, как процесс устроен на самом деле.

как исправить ошибку, из-за которой платёж дублируется или зависает

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

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

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

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

что делать, если ошибка повторяется после исправления

Если баг вернулся через пару обновлений — почти всегда это значит, что исправили симптом, а не причину. Дубль перевода мог пропасть на одной версии мобильной ОС, но остаться на другой; или исчезнуть на Wi-Fi, но проявиться на мобильном интернете с плохим сигналом у конкретного оператора.

В такой ситуации разбор начинают заново, но с другим вопросом: не «почему не сработало исправление», а «что мы не учли в первый раз». Смотрят полный набор устройств и версий ОС, а не только те, на которых баг воспроизводился изначально; проверяют поведение при разных операторах связи и разных банках-эквайерах, если приложение принимает оплату через несколько платёжных провайдеров; и главное — добавляют для этого сценария отдельный автоматический тест, чтобы при следующей правке кода регресс поймали автотесты, а не жалоба клиента в поддержку.

В одном B2B-проекте с интеграцией на 1С похожая история была с синхронизацией статусов заказа: ошибка «пропадала» на тестовой базе с десятком документов и возвращалась на боевой базе клиента с тысячами заказов в очереди — воспроизвести её получилось только на копии реальной базы, а не на демо-данных.

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

как предотвратить повторение ошибок в банковском приложении

Профилактика держится на нескольких вещах, которые работают только вместе.

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

Для компаний, которым по внутренним требованиям или требованиям контрагентов нужно подтверждать статус приложения в реестре российского ПО, эту проверку тоже встраивают в приёмку — до того, как релиз объявили готовым, а не после запроса от службы безопасности партнёра.

сколько стоит тестирование в разработке банковского приложения

Мы закладываем тестирование в разработку с самого начала, а не выставляем отдельным счётом после того, как заказчик находит баги сам. Для банковских и финтех-проектов это функциональные, нагрузочные и security-тесты на каждом релизном цикле, а для B2B-приложений — ещё и отдельная проверка интеграции с учётной системой заказчика: синхронизация данных приложения с 1С тестируется отдельно, потому что расхождение остатков или задвоенный документ в базе — это уже не баг интерфейса, а ошибка в бухгалтерии.

Если мобильное приложение построено на 1С:Мобильной платформе, часть проверок идёт через штатные механизмы платформы, но нагрузочное и security-тестирование всё равно проводят отдельно — платформа не снимает эту задачу с разработчика.

Разработка мобильного приложения под ключ у нас начинается от 500 000 рублей, и в эту стоимость входит тестирование на всех этапах, а не только финальная проверка перед публикацией в сторе. Если приложение обслуживает не конечных клиентов, а сотрудников или партнёров компании, посмотрите на B2B-приложение с интеграцией 1С — там тестовый контур строится вокруг бизнес-процессов заказчика, а не общих сценариев банковского клиента. Полный состав работ на каждом тарифе — на странице цены и тарифы.

❓ Частые вопросы

Сколько времени занимает тестирование мобильного банковского приложения?

Зависит от объёма функций, но обычно это от двух до четырёх недель параллельно с разработкой: функциональные и нагрузочные тесты идут на каждом релизном цикле, а security-тестирование и приёмочные испытания — перед сдачей финальной версии заказчику.

Нужно ли отдельно тестировать интеграцию с 1С в B2B-приложении?

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

Что будет, если пропустить нагрузочное тестирование перед акцией или зарплатным днём?

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

Как часто нужно проводить security-тестирование готового приложения?

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

Входит ли тестирование в стоимость разработки мобильного приложения или оплачивается отдельно?

У нас тестирование входит в стоимость разработки с самого начала — от 500 000 рублей за проект под ключ, включая функциональные, нагрузочные и security-тесты, а не выставляется отдельным счётом после того, как баги находит сам заказчик.