Decision table testing for banking rules is a test design technique that maps combinations of business conditions to expected actions. It helps QA teams turn rules such as payment authorisation, fee waivers or account eligibility into a structured set of test cases, making gaps, overlaps and unintended outcomes easier to find before release.
When to use decision table testing for banking rules
Use a decision table when an outcome depends on several conditions, especially when requirements describe combinations in prose. A payment decision might depend on card status, available spending limit and merchant restrictions. A fee rule might depend on account type, qualifying deposits and the customer’s package.
The table makes the rule logic visible to testers, product owners and developers. It also gives each distinct rule combination a basis for a test case. This is useful for business rules testing during requirements review and regression testing after a rule or configuration change.
Build the table from approved rules
Start with the authoritative business requirement or policy. Confirm its scope, effective date and owner, then identify:
- Conditions: inputs that can affect the decision, including valid values and how missing or invalid values are handled.
- Actions: observable outcomes, such as approve, decline, apply a fee or route for review.
- Preconditions: what must be true before this rule applies, such as a valid payment request in a supported currency.
Keep the conditions independent where possible. If two conditions describe the same fact, clarify the rule before deriving tests. Record the source requirement for each rule so that reviewers can confirm the table reflects approved policy rather than assumptions.
Worked example: card transaction authorisation
The following illustrative rule set assumes a valid transaction request. Real authorisation rules depend on the bank’s approved policy and may include further checks.
| Condition or action | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Card active? | Yes | No | Yes | Yes |
| Amount within available spending limit? | Yes | - | No | Yes |
| Merchant permitted? | Yes | - | - | No |
| Action: authorise | Yes | No | No | No |
| Action: decline | No | Yes | Yes | Yes |
A dash means the condition does not affect that rule’s outcome. The four rules are mutually exclusive and cover the combinations in this example: an inactive card declines; an active card exceeding its limit declines; an active card within its limit is declined when the merchant is restricted; and only the remaining combination is authorised.
Before using the table, check that the requirement defines how available limit is calculated and whether the boundary amount is permitted. If the rule says a transaction may use the full available limit, an amount exactly equal to that limit should be accepted. Test just below, at and just above the boundary to confirm the implementation follows that definition.
Derive and verify the test cases
Create at least one test for each distinct rule, with controlled test data for the conditions. For Rule 1, use an active card, an amount within the available limit and a permitted merchant; assert an authorisation response. For Rule 3, use an active card, an amount above the limit and a permitted merchant; assert a decline and the expected reason code if the requirement specifies one.
Vary conditions marked with a dash in selected tests. For example, test Rule 2 with both a permitted and a restricted merchant. Both outcomes should remain declines. This checks that a condition treated as irrelevant in the table does not change the result in the implementation.
Run the cases against the decision service or relevant application flow, and assert the externally observable result. Check related effects only where the rule requires them, such as an authorisation hold or an audit event. Use the same rule configuration and data assumptions as the test environment; configuration drift can make a valid test appear to fail or conceal a rule defect.
Review the table for missing combinations, conflicting outcomes and conditions that lack a defined value. Where several rules overlap, clarify the required precedence or revise the conditions so each combination has one expected outcome. Keep the table and test cases aligned when policy changes, then rerun affected cases alongside relevant regression tests.
Frequently asked questions
What should testers do when two decision table rules match the same input?
Treat overlapping rules as an ambiguity unless the approved policy defines precedence. Clarify the intended priority with the rule owner, then make the rules mutually exclusive or document and test the precedence explicitly.
How can a decision table support audit evidence?
Link each rule to its source requirement and each test case to the rule it verifies. Retain the input values, observed result, execution status and relevant rule or configuration version so reviewers can trace the decision.
Can decision tables represent rules that use date or amount ranges?
Yes. Define clear partitions such as before, on or after an effective date, or below, equal to or above a threshold. Test the boundary values and confirm that every valid range has an expected outcome.