Risk-based testing for development banks

Risk-based testing for development banks is a way to select and order software tests according to the potential consequences and likelihood of failure. It directs limited testing time towards functions that could affect loan or grant disbursement, project delivery, financial records, controls or development outcomes, while retaining evidence of the risks that remain.

How to assess risk in a development bank

Start with business processes and their intended outcomes, rather than ranking test cases in isolation. A development bank may support sovereign programmes, infrastructure projects, small businesses or other development initiatives. Its systems can connect financing decisions and agreements with disbursement, accounting, project monitoring and portfolio reporting. The relevant processes and consequences vary by institution and product.

For each process or requirement, record:

• Impact: What could happen if the function fails? Consider incorrect or delayed disbursement, inaccurate balances or reports, a missed approval, or disruption to a funded project.
• Likelihood: How plausible is failure, given recent changes, implementation complexity, historical defects and dependencies on other systems or organisations?
• Controls and detectability: What approvals, reconciliations or monitoring could prevent or detect the failure? Would they detect it before funds move or a report is issued?
• Exposure: Which borrowers, projects, currencies, products or reporting periods could be affected, and how widely?

Use these factors to agree a risk rating with business, technology and control owners. A simple high, medium or low scale can be sufficient if each rating has a recorded rationale. Avoid treating a score as objective when teams have not agreed what its terms mean. Separate the impact of a software defect from the likelihood of that defect: a rare failure can still deserve priority if its consequences are severe.

Turn the assessment into a test plan

Map each higher-rated risk to one or more test conditions, expected results, test data and evidence. Include the relevant test level: unit or component tests for calculations and rules, API or integration tests for interfaces, and end-to-end tests for workflows that cross applications or teams. Keep lower-risk areas in scope where required by acceptance criteria, controls, contracts or release policy.

For development finance workflows, examine both the intended route and conditions that should stop or defer processing. Depending on the system, this can include approval limits, milestone evidence, agreement conditions, currency handling, duplicate instructions, partial disbursements and failed downstream postings. Check connected records as well: an approved disbursement may need to appear consistently in the loan subledger, general ledger and project reporting. See Integration testing in banking for the role of interface checks.

Prioritisation should account for dependencies. A change to a shared customer, project or exchange-rate service can affect several products, even when the visible change is small. Review changed requirements, code, configuration and interfaces alongside known defect history. Select regression tests that cover affected high-risk paths, then add focused tests for plausible failure modes. Risk-based regression testing in banking covers this selection in more detail.

Practical example: milestone disbursement

Suppose a release changes how a project loan can be disbursed after a milestone is approved. A useful risk statement is: “A disbursement may be released without a valid approval, or may be posted twice after a timeout.” The first condition could bypass a control; the second could overstate the amount paid and distort account balances or project records.

Prioritise tests that verify an authorised user can approve the milestone, an unauthorised user cannot, and the disbursement remains blocked when required evidence is absent. Then test a valid approval through to the payment instruction and accounting entries. Simulate a timeout followed by a retry and confirm that the transaction is not duplicated. Assert the approved amount, currency, project and loan identifiers, resulting balances, and audit records. Use controlled test data and a stable environment; an unavailable payment simulator or inconsistent reference data can make a failure inconclusive.

Verify coverage and review residual risk

Review whether every high-rated risk has a test, a documented reason for omission, or another agreed control. Test results should link back to requirements or risk statements and identify the build, environment, data conditions and outcome. Investigate failed tests to distinguish product defects from environment drift, invalid data or third-party failures.

Reassess priorities when scope, business rules, interfaces or dependencies change, and before release when new defects alter the likelihood or impact assessment. Record untested risks and their owners so release decision-makers can judge the remaining exposure. Risk-based testing helps focus effort; it does not establish that an untested function is safe or replace required control checks.