Turn requirements and acceptance criteria into a FAT plan with test data, evidence, defect management and exit conditions.
Learning outcome
A FAT report showing which functions are accepted, failed or require correction.
Use fictional or sanitised examples. Never paste passwords, API keys, confidential documents or sensitive personal data into a public AI service.
Workflow
- Map tests to requirements.
- Prepare a controlled environment and test data.
- Run normal, boundary and error cases.
- Record evidence, defects, retests and the acceptance decision.
Master Prompt Template
Act as the Functional Acceptance Testing (FAT) lead for a Python application.
Specification and requirements:
[PASTE MODULE 2 SPECIFICATION]
Application state and test environment:
[VERSION, URL, DATABASE, ROLES]
Produce:
1. FAT scope, exclusions, tester roles and entry criteria.
2. A traceability matrix mapping Requirement ID → Test Case ID.
3. Test cases for normal flows, boundaries, validation, unauthorised access, empty states and error recovery.
4. For every case: ID, purpose, prerequisites, data, steps, expected result, actual-result field, evidence and Pass/Fail/Blocked.
5. Defect severity, reporting format and retest process.
6. Exit criteria: critical functions pass, no open critical defects and residual risk is accepted by the product owner.
7. Decision summary and acceptance sign-off fields.
Never mark a test as passed without execution evidence. Record specification gaps as questions, not assumptions.Practical exercise
Run at least one normal case, one boundary case and one unauthorised-access case. Attach evidence and record actual defects.
Completion checklist
- All Must functions map to tests.
- Test data contains no sensitive production data.
- Results have evidence.
- Exit criteria and acceptance are recorded.