State transition testing for banking workflows is a technique for checking that a workflow moves between defined states only when permitted events and conditions occur. It verifies valid transitions, blocked transitions and the effects of each transition, such as a payment status change, an account balance update or an audit record.
How state transition testing works
A test model defines the states a workflow can occupy, the events that can move it between states, and any guards that must be satisfied. A guard is a condition that controls whether a transition is allowed, such as a sufficient available balance or approval from an authorised user. A transition may also trigger actions, including posting ledger entries or sending a notification.
For a payment workflow, states might include Draft, Awaiting approval, Processing, Completed and Rejected. Events might include Submit, Approve, Reject and Settlement confirmed. The model should specify which events are allowed in each state. For example, a completed payment should not return to Draft through the normal submission action.
The test suite exercises permitted paths and attempts prohibited ones. It checks the resulting state and any relevant side effects. Coverage can be measured across states and transitions; transition-pair coverage checks sequences of two transitions, which can reveal defects that isolated transition tests miss.
What to verify in a banking workflow
For each transition, define its preconditions, expected new state and observable effects. A payment moving to Completed may require a settlement confirmation and should produce the posting behaviour specified for that workflow. A rejected payment should retain its rejection reason if the system records one. The expected balance treatment depends on the bank's defined posting policy, so tests should assert that policy rather than assume when funds are reserved or booked.
Check invalid events as well as valid paths. Examples include approving a payment that is already rejected, submitting a payment with a missing approval, or processing a payment after cancellation. Verify that the event is refused or handled as specified, the state remains valid, and no unintended financial posting occurs.
State checks should include more than the label shown in a user interface. Where available, inspect the persisted workflow record, API response, ledger or subledger entries, audit history and relevant downstream status. In a multi-system workflow, confirm that status changes propagate as required and that retries do not create duplicate transactions. Use controlled test data and record the starting balances and workflow state so that failures can be reproduced.
Practical example: a payment requiring approval
Assume a test payment of £120 starts in Draft, requires approval, and is expected to debit the sender and credit the recipient when completed. The exact posting point must follow the documented payment policy.
| Starting state | Event and condition | Expected result |
|---|---|---|
| Draft | Submit with valid payment details | Awaiting approval; no completion posting |
| Awaiting approval | Approve by an authorised approver | Processing; approval recorded |
| Processing | Receive settlement confirmation | Completed; expected debit and credit recorded once |
| Awaiting approval | Reject with a valid reason | Rejected; no completion posting |
| Completed | Submit again | Rejected or safely ignored; no duplicate posting |
Run the valid path and the rejection path, then try the invalid resubmission. Verify the state in the application and the resulting transaction records. If a settlement confirmation is delivered twice, assert that the workflow remains consistent and the payment is not posted twice.
Dependencies and limits
The model depends on accurate business rules, including role permissions, approval thresholds, cut-off handling and the timing of financial postings. If these rules are unclear, the model can encode an incorrect workflow and produce misleading results. Confirm rules with the relevant requirements and workflow owners before treating model coverage as evidence of correctness.
Banking workflows may also wait for asynchronous responses from payment services or other systems. Tests need a controlled way to trigger or simulate those responses, along with defined handling for timeouts, delayed messages and retries. Environment drift, stale test data or unavailable dependencies can make a transition test fail for reasons outside the workflow logic.
State transition testing focuses on states and allowed sequences. It complements end-to-end testing, which checks a broader customer or operational journey across integrated systems, and decision table testing, which is useful when many combinations of rules determine an outcome. Model-based testing can use the state model to generate or organise tests, while the model itself still needs review against the actual banking rules.
Frequently asked questions
How should a team handle a workflow with many possible states?
Model only states that represent meaningful differences in permitted actions or outcomes. Separate independent dimensions, such as payment status and approval status, where that keeps the model clearer, then prioritise combinations according to business risk.
Can state transition testing cover user permissions?
Yes. Include the actor or role as a transition condition and test that authorised roles can perform the action while unauthorised roles cannot. Also check that a denied action leaves the workflow and financial records unchanged.
How does state transition testing differ from decision table testing?
State transition testing focuses on how events move a workflow between states over time. Decision table testing focuses on combinations of conditions and the corresponding outcomes, and can help define guards within a transition model.
What evidence is useful when a transition test fails?
Capture the starting state, event and input data, actor, expected and actual states, relevant timestamps, system responses and associated audit or transaction records. This helps distinguish a workflow defect from a dependency or test-environment failure.