Net banking test cases, where the defect costs real money

The duplicate debit is the defect this set exists for. A transfer is not a read: retrying it is not safe unless the server can recognise that it has already seen that instruction. Mobile networks drop responses constantly, users press confirm again when nothing happens, and client libraries retry automatically on timeout. Any of those produces a second identical request. The fix is an idempotency key generated before the first attempt and reused on every retry, with the server returning the original result rather than performing the work again. Testing on a stable office connection will never surface it.

Concurrency is the second, and it is invisible in sequential testing. Two transfers that each read a balance of 10,000, each decide that 8,000 is affordable, and each then write their result will both succeed. The account ends up overdrawn by an amount that no single test case would predict. This needs a conditional update or a lock on the balance row, and it needs to be tested by firing requests simultaneously rather than one after another.

Limits are routinely enforced in the wrong place. A daily cap belongs to the account, not to the session or the channel, so a cap that is checked in the browser form is bypassed by the mobile app, and one that is checked per session is bypassed by opening two. The same applies to the second factor: a code that is not bound to the amount and the beneficiary can be requested for a small transfer and spent on a large one.

Finally, money is not a floating point number. Amounts should be held as integers in minor units, because a rounding residue that is invisible on one transaction becomes a reconciliation break across a day of them. The test that catches this is not on the transfer screen at all: it is the one that adds up every entry on the statement and checks that the total equals the closing balance.