How to Write Test Cases

Review of the draft (step 1). Your wording may differ; seven or more of these findings is a full answer. (1) No ID, so bug reports and test reports cannot refer to the case. (2) The title "Transfer test" names the feature, not a behaviour. (3) No preconditions: the starting balances are not stated, so nobody can say which balances to expect afterwards. (4) Step 2 makes the case depend on TC-DEP-03 having run first, so the suite cannot run in any order; the balance the case needs belongs in its preconditions. (5) The customer and his accounts were copied from production: real customer data has no place in test cases, least of all in banking; use a synthetic test customer. (6) The test data is vague: "some money" and "a big amount" are not values, so two testers would run two different tests. (7) Step 3 holds several actions and three behaviours — a valid transfer, the 20,000.00 SAR limit and the balance check — so when it fails, nobody knows which part broke. (8) "Transfer works correctly and an error is shown" cannot be judged pass or fail: which balances, which message, and is a reference number shown? (9) No priority, no type and no traceability to PAY-31 and its criteria. Four of these are common mistakes named in the guide: several things tested in one case (7), a vague expected result (8), a step that depends on another case (4) and real customer data (5).

Split (step 2): the draft tests three behaviours, so it becomes three cases — the valid transfer (TC-PAY31-01), an amount above the limit (TC-PAY31-05) and an amount above the balance (TC-PAY31-09). Each negative case breaks exactly one rule: the limit cases transfer from the savings account, whose balance is above 20,000.00 SAR, and the balance cases use amounts inside the limit, so a failure points to one rule. All cases start from the same synthetic data set, restored before each run: test customer CUST-T-031 with savings account SAV-2002 at 25,000.00 SAR and current account CUR-1001 at 5,000.00 SAR, both active, with no pending transactions; TC-PAY31-11 and TC-PAY31-12 add the shared account and the second test customer they name.

TC-PAY31-01 in full (step 3). Title: A transfer between own accounts moves the amount and shows a reference number. Priority: High. Type: Positive, also a smoke candidate. Requirement: PAY-31 AC1. Preconditions: CUST-T-031 is signed in; SAV-2002 has an available balance of 25,000.00 SAR and CUR-1001 has 5,000.00 SAR. Test data: source SAV-2002, destination CUR-1001, amount 250.00. Steps: 1. Open "Transfers". 2. Choose "Between my accounts". 3. Select SAV-2002 in "From". 4. Select CUR-1001 in "To". 5. Enter 250.00 in "Amount". 6. Tap "Confirm". Expected result: a confirmation with a reference number is shown; SAV-2002 shows 24,750.00 SAR and CUR-1001 shows 5,250.00 SAR. Postconditions: both balances have changed; restore the data set before the next run.

TC-PAY31-09 in full. Title: A transfer 0.01 SAR above the available balance is refused with "Insufficient balance". Priority: High. Type: Negative, boundary. Requirement: PAY-31 AC3. Preconditions: CUST-T-031 is signed in; CUR-1001 has an available balance of 5,000.00 SAR and SAV-2002 has 25,000.00 SAR. Test data: source CUR-1001, destination SAV-2002, amount 5000.01 — the balance plus 0.01, and inside the AC2 limit, so only AC3 is broken. Steps: 1. Open "Transfers". 2. Choose "Between my accounts". 3. Select CUR-1001 in "From". 4. Select SAV-2002 in "To". 5. Enter 5000.01 in "Amount". 6. Tap "Confirm". Expected result: the message "Insufficient balance" is shown; no confirmation and no reference number appear; CUR-1001 still shows 5,000.00 SAR and SAV-2002 still shows 25,000.00 SAR. Postconditions: none, the balances are unchanged.

The rest of the set (step 4), one line per case; with the two above it makes 14 cases. TC-PAY31-02 [Boundary · AC2] Amount 1.00, the lower edge, from SAV-2002: accepted; SAV-2002 shows 24,999.00 and CUR-1001 shows 5,001.00. TC-PAY31-03 [Boundary · AC2] Amount 0.99: "Confirm" stays disabled, the message "Enter an amount from 1.00 to 20,000.00 SAR" is shown under the field, and no balance changes. TC-PAY31-04 [Boundary · AC2] Amount 20000.00, the upper edge, from SAV-2002: accepted; SAV-2002 shows 5,000.00 and CUR-1001 shows 25,000.00. TC-PAY31-05 [Boundary · AC2] Amount 20000.01 from SAV-2002: "Confirm" stays disabled and the same message is shown; the balance of 25,000.00 makes sure only the limit is broken. TC-PAY31-06 [Negative · AC2] Amount 10.005, with three decimal places: not accepted; whether the message appears or the third decimal cannot be typed at all is Q1. TC-PAY31-07 [Negative · AC2] "Amount" left empty: "Confirm" stays disabled (whether the message also appears is part of Q1).

TC-PAY31-08 [Boundary · AC3] Amount equal to the available balance, 5000.00 from CUR-1001: accepted, because AC3 forbids going below zero, not reaching it; CUR-1001 shows 0.00 and SAV-2002 shows 30,000.00. TC-PAY31-10 [Negative · AC1] Once SAV-2002 is chosen in "From", it cannot be chosen in "To"; how this is shown is Q3. TC-PAY31-11 [Negative · role] An account that another customer shared with CUST-T-031 with view-only access (VIEW-3003) is not offered in "From"; whether it is offered in "To" is Q4. TC-PAY31-12 [Negative · AC1 precondition] Test customer CUST-T-032 holds one active and one closed account: the closed account is not offered and no transfer can be made; what the customer sees is Q5. TC-PAY31-13 [Negative · dependency] The core banking system does not respond after "Confirm" (simulated in the test environment, for example with a stub): no confirmation is shown, and there is no half-done transfer — either both balances change once or neither changes; the message and the retry behaviour are Q6. TC-PAY31-14 [Negative · AC1, concurrent actions] "Confirm" tapped twice quickly with 250.00 from SAV-2002 to CUR-1001: exactly one transfer and one reference number; SAV-2002 shows 24,750.00, not 24,500.00, and CUR-1001 shows 5,250.00. If you follow the guide’s six-value boundary pattern (three values at each edge), also add 1.01 and 19999.99 from SAV-2002 and, at the balance edge, 4999.99 from CUR-1001; all three are accepted.

Coverage (step 5): AC1 is covered by TC-PAY31-01, 10, 12, 13 and 14; AC2 by 02 to 07; AC3 by 08 and 09; the view-only role by 11. Every criterion has at least one positive and one negative case. The guide expects about eight to fifteen cases for a story with three criteria; what makes a set complete is not the count but that every criterion, every boundary, every kind of user and the failure of the dependency is covered.

Questions for the product owner: Q1 Is a third decimal place blocked while typing, or accepted and answered with the AC2 message? Does that message also appear while "Amount" is still empty? Are amounts with a thousands separator (1,000.00) or with Arabic-Indic digits accepted? Q2 Does the "available balance" in AC3 exclude pending card payments and holds? Q3 Is the source account removed from "To", or is a message shown? Q4 Can money be sent to a view-only shared account, or is it hidden from both lists? Q5 What does a customer with fewer than two active accounts see under "Between my accounts"? Q6 When the core banking system does not answer, which message is shown, may the customer retry, and what stops a retry from moving the money twice? Q7 Is 20,000.00 SAR per transfer the only limit, or is there also a daily total?

Check your own work: the title of each full case should name one behaviour, and each line of your list should check one behaviour; each case should start from stated preconditions, not from another case, use exact synthetic values, and have an expected result that two testers would judge the same way. In ISTQB terms, PAY-31 and its criteria are the test basis, each line of your list covers a test condition, and each full case has the preconditions, inputs, expected results and postconditions that the ISTQB glossary lists in its definition of a test case. If your set did not have TC-PAY31-08 (amount equal to the balance), TC-PAY31-13 (dependency failure) or TC-PAY31-14 (double tap), add them: the first is the edge that AC3 allows, the second is the dependency failure that the guide’s method for user stories asks for, and the third is one of the concurrent actions in the guide’s list of negative tests.