Testing money-moving features
Release validation for a fintech app, and a sample suite that checks the rules a bank cannot break.
- Organisation
- Waya Bank, Lagos
- My role
- AI & QA Engineer
- When
- 2026
- Stack
- Python, Test design, Property-based testing, Concurrency testing
Problem statement
Every release of a banking app can break something that costs real money: a fee posted twice, a retry that sends money twice, a race that overdraws an account.
Objectives & goals
- Validate workflows and data across releases
- Find reliability defects before customers do
- Escalate with evidence engineers can act on
Process
- DiscoverLearned the transfer, limit and reversal rules.
- DefineA test matrix of what could go wrong and what should happen.
- BuildExample tests, concurrency tests and randomised invariant tests.
- ProveReported defects with reproduction steps.
Who it's for
Expect their balance to be right, always.
Need clear, reproducible defect reports.
Challenges
- Retries after timeouts
- Many transfers at the same instant
- Edge cases nobody thought to write down
What I built
Ten cases from happy path to reversals.
50 transfers fired at once never overdraw.
2,000 random transfers: total money never changes.
Every rejection has a code a tester can assert on.
Flow
- Read the rules
- Write the matrix
- Example tests
- Concurrency tests
- Property tests
- Report defects
Results
Tools & languages
The code
An invented wallet service as the system under test, with the full matrix. 10 tests.
The repository is private. I'm happy to share it with a hiring team or walk you through it on a call.
Samples are written with synthetic data. No client code or client data is used.