Как выбрать мануального тестировщика для финтех-проекта: 5 обязательных критериев
При тестировании банковских приложений, многие ошибочно полагают, что главное — найти QA-инженера с опытом. Но в финтехе важно глубоко понимать специфику работы финансовых систем. Одна ошибка в расчётах или процессинге платежей может обернуться миллионными убытками и серьёзными репутационными рисками.
За 7 лет работы с банками и финтех-компаниями мы в LeanTech выделили 5 ключевых критериев, которые стоит учитывать при подборе мануального тестировщика. Эти требования сформированы на основе реальных кейсов — с учётом как технических, так и регуляторных аспектов отрасли.
За 7 лет работы с банками и финтех-компаниями мы в LeanTech выделили 5 ключевых критериев, которые стоит учитывать при подборе мануального тестировщика. Эти требования сформированы на основе реальных кейсов — с учётом как технических, так и регуляторных аспектов отрасли.
- Почему мануальное тестирование по-прежнему критично
- Как выбрать мануального тестировщика для банковских приложений: ключевые требования к опыту
- Инструменты: анализ всей системы
- Регуляторное тестирование: когда нет права на ошибку
- Безопасность: базовые проверки обязательны
- Soft skills: от репорта до релиза
Почему мануальное тестирование по-прежнему критично
Несмотря на стремительное развитие автоматизации, 80% критических уязвимостей в банковских приложениях до сих пор выявляются вручную. Особенно это касается следующих сценариев:
Сложные пользовательские цепочки (например, оформление ипотеки через мобильное приложение)
Проверка на соответствие регуляторным требованиям
Тестирование интеграций с внешними системами (ЦБ, ФНС, ГИС ЖКХ и др.)
Мануальное тестирование — необходимый уровень глубины, особенно в сфере с высокой стоимостью ошибки.
Как выбрать мануального тестировщика для банковских приложений: ключевые требования к опыту
Почему вопрос «У вас был опыт с банковскими системами?» не работает.
На 10 собеседованиях 8 кандидатов ответят «да», но реальное понимание процессов есть у единиц. Поэтому мы оцениваем факты, а не заявления.
Как проверить реальный опыт:
При изучении резюме кандидата важно обращать внимание не просто на общее упоминание «банковского приложения», а на то, с какими модулями и задачами он реально работал. Ценен опыт, связанный с расчётом процентов по вкладам, проверкой клиентов в рамках требований 115-ФЗ, интеграцией с платёжными шлюзами, а также участием в разработке бизнес-кабинетов и функциональности шаблонов платежей. Это говорит о глубоком погружении в реальные процессы финтеха.
Также важно, чтобы тестировщик не просто знал аббревиатуры, а понимал, как применять стандарты на практике. Например, в рамках PCI DSS — мог объяснить, как убеждался, что данные карты не записываются в логи; в части 115-ФЗ — какие сценарии использовались для проверки подозрительных операций; а в соответствии с ГОСТ Р 57580 — как тестировалась корректность формирования электронных чеков.
Имеет значение опыт, который невозможно подделать — реальные кейсы из практики. Полезно попросить кандидата рассказать о самой критичной ошибке, которую ему доводилось находить, опыте тестирования валютных переводов или о том, как он проверял записи транзакций в базе данных после операций. Такие детали позволяют понять, насколько кандидат ориентируется в финтех-процессах не только теоретически, но и в боевых условиях.
Из нашей практики:
Один из кандидатов при тестировании мобильного банка обнаружил, что система при определённом сценарии:
На 10 собеседованиях 8 кандидатов ответят «да», но реальное понимание процессов есть у единиц. Поэтому мы оцениваем факты, а не заявления.
Как проверить реальный опыт:
При изучении резюме кандидата важно обращать внимание не просто на общее упоминание «банковского приложения», а на то, с какими модулями и задачами он реально работал. Ценен опыт, связанный с расчётом процентов по вкладам, проверкой клиентов в рамках требований 115-ФЗ, интеграцией с платёжными шлюзами, а также участием в разработке бизнес-кабинетов и функциональности шаблонов платежей. Это говорит о глубоком погружении в реальные процессы финтеха.
Также важно, чтобы тестировщик не просто знал аббревиатуры, а понимал, как применять стандарты на практике. Например, в рамках PCI DSS — мог объяснить, как убеждался, что данные карты не записываются в логи; в части 115-ФЗ — какие сценарии использовались для проверки подозрительных операций; а в соответствии с ГОСТ Р 57580 — как тестировалась корректность формирования электронных чеков.
Имеет значение опыт, который невозможно подделать — реальные кейсы из практики. Полезно попросить кандидата рассказать о самой критичной ошибке, которую ему доводилось находить, опыте тестирования валютных переводов или о том, как он проверял записи транзакций в базе данных после операций. Такие детали позволяют понять, насколько кандидат ориентируется в финтех-процессах не только теоретически, но и в боевых условиях.
Из нашей практики:
Один из кандидатов при тестировании мобильного банка обнаружил, что система при определённом сценарии:
- Списывала деньги со счёта
- Не зачисляла их получателю
- Не отражала операцию в истории
- Выдавала некорректный чек
Красные флаги:
- Общие фразы без примеров
- Незнание терминов: эквайринг, p2p, корсчёт
- Непонимание жизненного цикла транзакции
Инструменты: анализ всей системы
Современный мануальный тестировщик — это гибридный специалист, работающий на стыке UI, backend и интеграций. Его инструментарий должен включать:
- Postman или аналогДля тестирования API и банковских методов
- SQL-запросыДля проверки записей по операциям и расчётам
- UI-тестированиеОт валидации форм до кроссбраузерной проверки
- ПрактикаПри тестировании перевода денег QA сначала отправляет API-запрос, проверяет отклик, затем сверяет данные в БД, и лишь потом переходит к UI. Такой подход выявляет ошибки, которые невозможно заметить, просто «прокликав» приложение.
Регуляторное тестирование: когда нет права на ошибку
Финансовое ПО должно работать не только корректно, но и в полном соответствии с законодательством. Одним из наиболее важных направлений является соблюдение требований 115-ФЗ при проведении операций от 600 000 рублей, где особенно важно корректно обрабатывать и фиксировать каждое действие.
Немаловажно обеспечить стабильные и точные интеграции с государственными системами, такими как Центробанк, МВД, ФНС и другие ведомства, поскольку любые сбои могут повлечь за собой юридические последствия.
Ещё одна критически важная область — точность финансовых расчётов и формирование отчётности: даже минимальные расхождения могут привести к штрафам. Так, в одном из наших проектов тестировщик выявил ошибку округления суммы в отчёте для ЦБ — отклонение всего на одну копейку. На первый взгляд это несущественно, но в отчётной документации такие расхождения недопустимы и могут повлечь серьёзные санкции.
Немаловажно обеспечить стабильные и точные интеграции с государственными системами, такими как Центробанк, МВД, ФНС и другие ведомства, поскольку любые сбои могут повлечь за собой юридические последствия.
Ещё одна критически важная область — точность финансовых расчётов и формирование отчётности: даже минимальные расхождения могут привести к штрафам. Так, в одном из наших проектов тестировщик выявил ошибку округления суммы в отчёте для ЦБ — отклонение всего на одну копейку. На первый взгляд это несущественно, но в отчётной документации такие расхождения недопустимы и могут повлечь серьёзные санкции.
Безопасность: базовые проверки обязательны
В финтехе ценность данных максимальна, тестировщик должен думать, как злоумышленник. Хотя пентест проводят отдельные команды, первичные уязвимости может находить и QA. Вот на что обращаем внимание:
Наиболее частые уязвимости:
Наиболее частые уязвимости:
- SQL-инъекции
- XSS-атаки
- Ошибки в механизмах аутентификации
Инструменты:
- OWASP ZAP — для базовых проверок безопасности
- Проверка кэширования чувствительных данных
- Контроль хранения токенов, cookie и сессий
Даже одна ошибка, связанная с кэшем или логами, может привести к утечке истории транзакций — и это уже инцидент с потенциальными исками.
Soft skills: от репорта до релиза
Даже идеально найденная ошибка теряет смысл, если её невозможно воспроизвести. В финтехе важно не только обнаружить баг, но и точно донести его суть до команды. Опытные тестировщики умеют описывать проблему так, чтобы у разработчиков не осталось вопросов: пошагово, без лишних деталей, с наглядными материалами — скриншотами, логами или видео. Особенно ценно, когда специалист может аргументированно объяснить, почему именно эта ошибка критична, и настоять на её исправлении до релиза.
В одном из проектов по запуску нового раздела мобильного банка тестировщик заметил, что при оформлении вкладов с капитализацией процентов система в определённых условиях некорректно рассчитывает итоговую сумму на длительных сроках (более 12 месяцев). Ошибка проявлялась только при пересечении нескольких факторов: нестандартная дата начала вклада, переход через високосный год и одновременное изменение ставки банком по текущим продуктам. На первый взгляд расчёты выглядели правдоподобно, и разработчики посчитали это особенностью бизнес-логики.
Тестировщик не просто зафиксировал расхождения в цифрах — он инициировал обсуждение на grooming-сессии, привёл ссылку на методику расчёта из регламентов ЦБ, показал разницу между фактической и ожидаемой суммой с учётом капитализации, а также собрал данные по аналогичным вкладам из боевой среды. Более того, он спокойно и чётко объяснил архитектору проекта, почему ошибка может повлиять на налоговые расчёты при выводе средств и вызвать вопросы у клиентов.
Команда согласилась вернуться к расчётной формуле, и в результате был выявлен дефект в алгоритме округления на последнем шаге расчёта. Ошибку устранили до релиза, а благодаря вовлечённости тестировщика в диалог с бизнесом и архитекторами, изменения были зафиксированы в документации и протестированы в дополнительных сценариях.
В одном из проектов по запуску нового раздела мобильного банка тестировщик заметил, что при оформлении вкладов с капитализацией процентов система в определённых условиях некорректно рассчитывает итоговую сумму на длительных сроках (более 12 месяцев). Ошибка проявлялась только при пересечении нескольких факторов: нестандартная дата начала вклада, переход через високосный год и одновременное изменение ставки банком по текущим продуктам. На первый взгляд расчёты выглядели правдоподобно, и разработчики посчитали это особенностью бизнес-логики.
Тестировщик не просто зафиксировал расхождения в цифрах — он инициировал обсуждение на grooming-сессии, привёл ссылку на методику расчёта из регламентов ЦБ, показал разницу между фактической и ожидаемой суммой с учётом капитализации, а также собрал данные по аналогичным вкладам из боевой среды. Более того, он спокойно и чётко объяснил архитектору проекта, почему ошибка может повлиять на налоговые расчёты при выводе средств и вызвать вопросы у клиентов.
Команда согласилась вернуться к расчётной формуле, и в результате был выявлен дефект в алгоритме округления на последнем шаге расчёта. Ошибку устранили до релиза, а благодаря вовлечённости тестировщика в диалог с бизнесом и архитекторами, изменения были зафиксированы в документации и протестированы в дополнительных сценариях.
Вывод: каким должен быть идеальный тестировщик для финтеха
Собираем портрет специалиста, которому можно доверить банковское приложение:
- Имеет опыт именно в финтехе
- Знает регуляторные требования
- Владеет ручными и техническими методами
- Мыслит с точки зрения безопасности
- Умеет работать в команде и доносить суть ошибок