Read references/index.md before executing any step.

Usage

Apply this skill when:

• A formal test plan document is needed for a sprint, feature, or module

• Stakeholders require a human-readable summary of testing strategy

• QA team needs a structured sign-off document

• An audit or compliance process requires test documentation

• A developer wants a Markdown test plan alongside their test file

Test Plan Document Structure

Every test plan must include these sections:

1. Cover Page / Header

Test Plan: <Feature or Module Name> Version: 1.0 Date: <date> Author: TestForge AI (test-unit-gen-agent) Status: Draft | Review | Approved

2. Scope

• What is being tested (module, feature, user story reference)

• What is explicitly OUT of scope (integration tests, performance tests, etc.)

• Target environments (local dev, CI, staging)

3. Test Objectives

Written as measurable goals:

• Achieve >= 80% line coverage for

• Verify all acceptance criteria in user story US-042

• Validate error handling for all invalid input types

4. Test Strategy

Approach Description

Unit Testing Isolated function/method testing with mocked dependencies

Framework <pytest / Jest / JUnit 5 / xUnit>

Coverage Tool <coverage.py / Istanbul / JaCoCo>

Execution <manual / CI via GitHub Actions / Jenkins>

BDD Style <Yes/No> — Gherkin scenarios used for requirements-driven tests

5. Test Cases Summary Table

6. Coverage Targets

Metric Target Current Gap

Line Coverage 80% 64% 16%

Branch Coverage 75% 51% 24%

Function Coverage 90% 78% 12%

7. Dependencies & Risks

Dependency Risk Mitigation

External payment API Tests may fail if mock schema changes Pin mock responses to spec version

Database schema Schema changes break fixture data Use factory-based fixtures, not hard-coded SQL

8. Entry & Exit Criteria

Entry Criteria (tests can begin):

• Source code or requirements are available

• Test environment is configured

• All dependencies are mockable

Exit Criteria (testing is complete):

• All HIGH priority test cases pass

• Coverage targets are met

• Test review agent verdict: APPROVED or APPROVED_WITH_NOTES

• No CRITICAL or HIGH severity defects outstanding

9. Defect Management

• Defects found during test execution logged in: <Jira / GitHub Issues / Linear>

• Severity levels: CRITICAL | HIGH | MEDIUM | LOW

• Blocking defects must be resolved before CI gate passes

10. Approvals

BDD / Gherkin Test Cases (when requirements-driven)

When the input includes user stories or acceptance criteria, supplement the test plan with Gherkin scenarios:

Feature: User Login

Scenario: Successful login with valid credentials Given a registered user with username "alice" and password "secret" When the user submits the login form Then the system returns a JWT token And the response status is 200

Scenario: Login fails with wrong password Given a registered user with username "alice" When the user submits login with password "wrong" Then the response status is 401 And the error message is "Invalid credentials"

Output Formats

Markdown (.md)

• Use this for developer-facing documentation

• Stored alongside test files in the repository

• Rendered in GitHub/GitLab automatically

Word Document (.docx)

• Use this for formal QA sign-off, audits, or stakeholder review

• Use the docx skill to generate the .docx file from the Markdown content

• Formatting: professional heading styles, page numbers, company letterhead

Quality Checklist

Before delivering the test plan:

• All test cases from the generated test suite appear in Section 5

• Coverage targets are specific and measurable (not just "high")

• Entry/exit criteria are unambiguous

• Test case IDs are unique and traceable to requirements where possible

• Document version and date are current

• Status column reflects actual state (Planned / In Progress / Pass / Fail)