Writing Test Scenarios for Happy Path and Negative Path

A happy path scenario proves that the normal journey works from start to finish. For example, a customer at Barclays sends 5,000 pounds to a supplier in Germany using a SEPA Credit Transfer. The scenario starts with a valid IBAN, a valid BIC, an amount of 5,000 euros, and a value date of today. The tester submits the payment, checks that a pacs.008 is created, confirms that the status changes to accepted, and verifies that the customer account is debited by 5,000 euros. The scenario ends with a pacs.002 acceptance and a camt.053 entry the next morning. Each step is clear and each expected result is measurable. A negative path scenario proves that the system fails safely when the input is wrong. If the same customer enters an IBAN with a wrong check digit, the system must reject the payment before it leaves the bank, show a clear error message, and keep the funds in the customer account. The tester must not see a pacs.008 created, a debit posted, or a vague system error. The expected result is a controlled rejection with a reason code, a log entry, and no money movement. That behaviour protects the customer from sending money to an invalid account. Negative testing must also cover business rule failures, not only format errors. A corporate user who tries to send 2 million dollars when the daily limit is 1 million dollars must be stopped by the limit control, with an approval request sent to a second authorised user. A payment with a missing remittance reference, a value date in the past, or a currency that the corridor does not support must also be rejected or queued for repair. Each of these cases needs its own scenario, because a system that handles one failure correctly may handle another failure badly. Duplicate detection is one of the most important negative paths in payments. If an operations user resubmits the same pain.001 file twice, or if a system retries a pacs.008 after a timeout, the bank must not send the money twice. A good scenario submits a 75,000 pound payment with reference INV-2026-8841, then resubmits the identical file, and expects the second submission to be flagged as a duplicate and blocked. The tester checks the ledger, the message log and the customer statement to prove that only one debit and one credit exist for that reference. Good scenarios also use realistic data and realistic boundaries. A tester should test a payment of 0.01 pounds, a payment of 999,999.99 pounds, a payment at the exact cut off time, and a payment one minute after the cut off. A tester should also test a payment in euros, dollars and pounds, and a payment to a sanctioned country that must be blocked. Each scenario needs a unique reference, a clear precondition, numbered steps and a precise expected result. When scenarios are written this way, any tester can execute them, and any reviewer can see exactly what was proven. A full scenario table makes the coverage visible. For a SEPA payment of 5,000 euros, the happy path proves the payment is created, screened, sent as a pacs.008, accepted with a pacs.002, debited, and confirmed on the camt.053 statement. The negative paths prove that a wrong IBAN check digit is rejected before any message is created, that an amount above the daily limit triggers a second approval, that a duplicate file with the same reference INV-2026-8841 is blocked, and that a payment to a sanctioned country is held. Each row in the table has a precondition, numbered steps, an expected result, and a place for the actual result. When the table is complete, the coverage is visible at a glance. Boundary testing is where most payment defects hide. A payment of exactly 0.01 pounds tests the minimum amount logic. A payment of 999,999.99 pounds tests the maximum field length. A payment submitted at 17:59 tests the cut-off handling, and one submitted at 18:01 tests the next-day queuing. A payment with a value date on a bank holiday tests the calendar logic. A payment with a remittance reference of exactly 140 characters tests the field limit. For a business analyst, the practical skill is to read the requirement, find every number and every limit in it, and write a test case at, just below, and just above each one. That is how boundary defects are found before customers find them.