Testing & Quality
Running a Core Banking acceptance phase without losing traceability
On a Core Banking programme, the difficulty is not running tests, but keeping a continuous thread between what was asked, what was tested and what was fixed. When that thread breaks, acceptance becomes theatre without guarantee.
From requirement to scenario, unbroken
Every test scenario must trace back to a precise requirement, and every requirement must be covered by at least one scenario. This coverage matrix is not bureaucratic paperwork: it is the instrument that answers, at any moment, the question “did we test what we promised?”.
The classic trap is to test what is easy rather than what is critical. Coverage driven by requirements, not by technical convenience, corrects that bias.
Test data is half the test
A banking scenario is only as good as the data feeding it: currencies, accounting schemas, interest-calculation edge cases, cut-off dates. Preparing this data often takes longer than writing the cases — and that is where the costliest defects hide.
Industrialising this data makes it possible to replay a campaign identically, a prerequisite for credible non-regression testing.
A defect is only useful if it is connected
An isolated defect is information; a defect tied to its scenario, its requirement and its fix is a decision. Defect tracking must therefore reach back to the requirement concerned, to measure the real residual risk before go-live.
Define exit criteria before starting
Acceptance exit criteria are defined at scoping, not on the eve of go-live. Without a clear threshold — coverage reached, blocking defects cleared — the production decision becomes political rather than factual.