The post has been translated automatically. Original language: Russian
Why do bugs appear in banking products?
Often, the team only tests the ideal scenario.:
the client created the payment → signed → the payment went to the bank.
But in reality, the process is more complicated.
For example, if a payment requires two signatures, it is important to check in advance.:
- what happens after the first signature;
- how will the status change after the second one;
- what happens if the certificate is invalid
- how will the system behave if the banking system is temporarily unavailable;
- will the error be recorded in the event log
- whether the payment will be lost on a second attempt.
If such scenarios are not described in advance, the error may be detected after the product is released into the work environment.
That is why testing is not just about checking the correct scenario. It is important to determine in advance how the system should behave in case of errors, failures and non-standard user actions.
From requirements to tests
A good approach is to turn every business requirement into specific conditions and expected results.
For example:
The payment should go to the bank only after two signatures.
So we're checking:
- after the first signature, the status is "Awaiting the second signature"
- after the second one, "Signed"
- if there is a certificate error, there is a clear message and a log entry.
- if the banking system is unavailable, it is a repeat attempt or queue, not a loss of payment.
Then these scenarios can be automated.:
- Software interface checks are the main business logic
- system interaction checks — correctness of data exchange
- Interface checks are the key way for the client: login → payment → signature → status
Before the release, it is useful to have a short set of critical checks that quickly shows whether the main functions are working after the changes.
But the control does not end after the release. In a production system, it is important to keep track of query errors, response time, retries, and other rejections.
The result is a cycle.:
requirement → scenarios → tests → release → monitoring.
This approach helps to find problems before the client encounters them.
Почему в банковских продуктах появляются баги?
Часто команда тестирует только идеальный сценарий:
клиент создал платеж → подписал → платеж ушел в банк.
Но в реальности процесс сложнее.
Например, если платеж требует две подписи, важно заранее проверить:
- что произойдет после первой подписи;
- как изменится статус после второй;
- что произойдет, если сертификат недействителен
- как система поведет себя, если банковская система временно недоступна;
- запишется ли ошибка в журнал событий
- не потеряется ли платеж при повторной попытке.
Если такие сценарии не описать заранее, ошибка может обнаружиться уже после выхода продукта в рабочую среду.
Именно поэтому тестирование - это не только проверка правильного сценария. Важно заранее определить, как система должна вести себя при ошибках, сбоях и нестандартных действиях пользователя.
От требования — к тестам
Хороший подход — превратить каждое бизнес-требование в конкретные условия и ожидаемые результаты.
Например:
Платеж должен уйти в банк только после двух подписей.
Значит, проверяем:
- после первой подписи — статус «Ожидает вторую подпись»
- после второй — «Подписан»
- при ошибке сертификата — понятное сообщение и запись в журнал
- если банковская система недоступна — повторная попытка или очередь, а не потеря платежа.
Дальше эти сценарии можно автоматизировать:
- проверки программного интерфейса — основная бизнес-логика
- проверки взаимодействия систем — корректность обмена данными
- проверки интерфейса — ключевой путь клиента: вход → платеж → подпись → статус
Перед релизом полезно иметь короткий набор критических проверок, который быстро показывает, работают ли основные функции после изменений.
Но контроль не заканчивается после релиза. В рабочей системе важно отслеживать ошибки запросов, время ответа, повторные попытки и другие отклонения.
В итоге получается цикл:
требование → сценарии → тесты → релиз → мониторинг.
Такой подход помогает находить проблемы до того, как с ними столкнется клиент.
Share
