UAT test cases

Design tests that prove each rule and requirement, with dates anyone can check against the published calendar.

From the first requirement onwards. Complete the set before the build is signed off. Inputs: the requirements, the user stories and the decision tables. Feeds: the traceability matrix.

• Test one behaviour per test, on one worked example, and mark as Negative any step that checks what the system must not do.
• Give exact test data (the worked example, the time and the date), and tag any data you chose yourself.
• Write the expected result as an outcome in the record or in a notice, never as "it works".
• Put every expected deadline in the three date columns, and let the formula check it against the Calendar sheet.
• Leave the result columns for the person who runs the test.

1. How do you know the expected deadline is right? Answered in Deadline check column: the WORKDAY formula recounts each deadline on the Calendar sheet (SRC-08), day 1 being the first working day after the date of receipt (DEC-03). Every row with a deadline shows OK; the nine tests with no deadline leave it empty.
2. Which rule does each test prove? Answered in Covers column; 19 lists the tests for each requirement.
3. Is there a negative test for each Must? Answered in Steps column: every Must is covered by at least one test with a step marked Negative. The three requirements with no test, REQ-05, REQ-16 and REQ-35, are a Should, a Could and a Won't (release 1); the gap notes in 19 say why.
4. Could another tester repeat it exactly? Answered in Test data column: the specimen request, the time and the date. TC-03, TC-09, TC-18 and TC-22 to TC-28 add data of their own, and TC-10 adds one detail to EX-04; all of it is tagged MINE. TC-21 adds the regulator's own example as a contrast, tagged GUIDE.
5. Were these tests run? Answered in Execution note: no. There is no system, and the result columns are empty on purpose.

• Expected dates worked out by hand. You can spot them when no formula or second count stands behind a date.
• Tests with no data: two testers would pick different dates and both pass.
• "System works" as an expected result: a wrong deadline would still pass the test.
• Pretending the tests were run: results appear and there is no system, or no tester and no date.
• No negative step where a rule says "must not": every test shows something happening and none shows something refused.

• The result columns are empty. There is no system to test: release 1 is not yet bought or built (DEC-14), so a filled "Pass" would be a claim nobody made. Rejected: sample results, which would look like evidence.
• Every expected deadline sits in three columns, so a formula can recount it on the Calendar sheet (SRC-08). WORKDAY never counts its start date. Started from the date of receipt, it counts the next working day as day 1, which is how DEC-03 reads the law. Rejected: deadlines in the text only, which nobody can recheck in bulk.
• TC-03, TC-09, TC-18 and TC-22 to TC-28 need data that no specimen request gives, and TC-10 needs one detail that EX-04 does not state. That data is tagged MINE and dated after the snapshot, like the specimen requests (DEC-11). TC-21's contrast is the regulator's own example, tagged GUIDE. Rejected: stretching a specimen request to cover a case it was not written for.
• TC-14 counts 40 working days from the date of receipt to the public interest decision: 20 to the notice and 20 more for the decision (BR-26, BR-27). Rejected: a separate start date for the extension, which would need a column no other test uses.