acceptance-test-plan

name	acceptance-test-plan
description	Produces a traceable acceptance test plan with individually numbered test cases. Each test case maps to a source requirement (user story, use case, or FR), specifies preconditions, steps, and expected results, and includes coverage of the happy path, edge cases, and negative scenarios.
version	1.0.0
tags	["testing","acceptance","test-plan","quality","requirements"]
metadata	{"skill-author":"Marie-Lynne Block"}

What this skill does

Produces a traceable acceptance test plan with individually numbered test cases. Each test case maps to a source requirement (user story, use case, or FR), specifies preconditions, steps, and expected results, and includes coverage of the happy path, edge cases, and negative scenarios.

When to use it

• User asks to "write a test plan", "create acceptance tests", or "define test cases" for a feature or system.
• A sprint is nearing completion and the team needs acceptance criteria turned into formal tests.
• A stakeholder or client needs documented evidence that acceptance criteria have been verified.
• User is preparing for UAT (User Acceptance Testing) and needs a test script.
• Use cases or functional requirements from a requirements-document need test coverage.

Key concepts

Test case anatomy

Field	Description
ID	Unique identifier (TC-NNN)
Title	Short description of what is being tested
Source	The story, use case, or FR this test covers
Type	Happy path / Edge case / Negative / Performance / Security
Priority	Critical / High / Medium / Low
Preconditions	State the system must be in before the test starts
Test steps	Numbered actions the tester performs
Expected result	What should happen if the system behaves correctly
Pass / Fail	To be filled in during test execution

Coverage types

Type	Purpose
Happy path	The main success scenario — everything goes right
Edge case	Boundary values, limits, and unusual-but-valid inputs
Negative	Invalid inputs, missing data, unauthorised access — system must handle gracefully
Performance	Response times, load behaviour — only if NFRs specify thresholds
Security	Access control, injection, data exposure — only if security NFRs are in scope

Minimum coverage rule

For every acceptance criterion or FR: at least one happy path test and at least one negative or edge case test.

Instructions

1. Identify the source material. User stories (with acceptance criteria), use cases, or functional requirements. If none are provided, ask before writing tests.

2. Define the test scope. Which stories, FRs, or use cases are in scope for this plan?

3. Identify test types needed. At minimum: happy path and negative. Add edge cases for inputs with boundaries, performance tests if NFRs specify thresholds, and security tests if access control is in scope.

4. Write test cases. For each acceptance criterion or FR:

   • Write the happy path test first.
   • Write at least one negative or edge case test.
   • Assign priority based on risk: Critical for core flows, High for error handling, Medium/Low for cosmetic or informational behaviour.

5. Write preconditions precisely. The tester must be able to set up the exact state without ambiguity.

6. Write expected results precisely. Not "it works" — describe the exact system response: message text, state change, data written, redirect destination.

7. Build the traceability matrix. Map each test case to its source requirement.

8. Produce the report using the format below.

Output format

# Acceptance Test Plan: [Feature / System name]

| Field | Detail |
| --- | --- |
| **Version** | 0.1 |
| **Date** | YYYY-MM-DD |
| **Author** | [name] |
| **Source requirements** | [Story IDs / UC IDs / FR IDs] |
| **Test environment** | [e.g., staging, QA environment] |
| **Tester** | [name or role] |

---

## Test summary

| Type | Count |
| --- | --- |
| Happy path | n |
| Edge case | n |
| Negative | n |
| Performance | n |
| Security | n |
| **Total** | **n** |

---

## Test cases

### TC-001 — [Title]

| Field | Detail |
| --- | --- |
| **Source** | [US-01 / UC-001 / FR-001] |
| **Type** | Happy path |
| **Priority** | Critical |
| **Preconditions** | [Exact system state required] |

**Steps:**

1. [Action the tester takes]
2. [Action the tester takes]
3. [Action the tester takes]

**Expected result:** [Precise description of what the system should do or display]

**Pass / Fail:** ___

---

### TC-002 — [Title]

| Field | Detail |
| --- | --- |
| **Source** | [US-01 / UC-001 / FR-001] |
| **Type** | Negative |
| **Priority** | High |
| **Preconditions** | [Exact system state required] |

**Steps:**

1. [Action]
2. [Action — with invalid/missing input]

**Expected result:** [Error message, rejection behaviour, or graceful degradation]

**Pass / Fail:** ___

---

## Traceability matrix

| Source | Test case(s) | Coverage |
| --- | --- | --- |
| US-01 AC1 | TC-001, TC-002 | Happy path + negative |
| US-01 AC2 | TC-003 | Happy path |
| FR-001 | TC-004, TC-005 | Happy path + edge case |

---

## Risks and assumptions

- [Any test environment limitations that may affect results]
 [Data dependencies or setup requirements]
 [Out-of-scope test types and why]

Examples

Example 1 — Login feature acceptance tests

Input: User story: "As a registered user, I want to log in with my email and password so that I can access my account." Acceptance criteria: valid credentials grant access; invalid credentials show an error; account locks after 5 failed attempts.

Expected output:

• TC-001 (Happy path): valid email + password → redirected to dashboard.
• TC-002 (Negative): invalid password → "Incorrect email or password" message shown, account not locked.
• TC-003 (Edge case): 5th consecutive failed attempt → account locked, user shown lockout message, email sent.
• TC-004 (Edge case): empty email field → form validation error before submission.

Example 2 — From use case output

Input: Use case UC-001 (Place order) with main flow and 3 extensions.

Expected output: TC-001 covers main success scenario. TC-002 covers extension 4a (out of stock). TC-003 covers extension 5a (payment declined). TC-004 covers extension 5b (payment timeout). Traceability matrix links all TCs to UC-001 steps.

Notes

• Test steps should be executable by someone unfamiliar with the system. Avoid "navigate to the order page" — write "open a browser, go to [URL], click 'My Orders'."
• Expected results must be deterministic. If the result varies by data state, specify the data setup in preconditions.
• Do not test implementation details (internal function calls, database queries). Test observable system behaviour only.
• This skill integrates with use-case (each extension → a test case), requirements-document (FRs → test cases in the traceability matrix), and write-user-story (acceptance criteria → test cases).