qa-test-management

Automatic QA test lifecycle management, naming conventions, and directory structure. Use when creating, organizing, or tracking QA tests to ensure proper naming, directory structure, and status transitions.

9 stars

Best use case

qa-test-management is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Automatic QA test lifecycle management, naming conventions, and directory structure. Use when creating, organizing, or tracking QA tests to ensure proper naming, directory structure, and status transitions.

Teams using qa-test-management should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/qa-test-management/SKILL.md --create-dirs "https://raw.githubusercontent.com/jpoutrin/product-forge/main/plugins/product-design/skills/qa-test-management/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/qa-test-management/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How qa-test-management Compares

Feature / Agentqa-test-managementStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Automatic QA test lifecycle management, naming conventions, and directory structure. Use when creating, organizing, or tracking QA tests to ensure proper naming, directory structure, and status transitions.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# QA Test Management Skill

Ensure consistent QA test organization, lifecycle management, and traceability.

## Automatic Behaviors

When working with QA tests, automatically:

1. **Apply naming conventions** for QA test files
2. **Maintain directory structure** for test organization
3. **Enforce status lifecycle** transitions
4. **Include required metadata** in all test files
5. **Link tests to PRD requirements** for traceability
6. **Track execution history** with dates and results

## Directory Structure

```
qa-tests/
├── draft/                    # Tests being written
│   └── QA-20250105-001-login.md
├── active/                   # Tests ready for execution
│   └── QA-20250104-002-checkout.md
├── executed/                 # Recently executed tests
│   └── QA-20250103-001-search.md
├── archived/                 # Historical tests
│   └── 2024/
│       └── QA-20241215-001-old-feature.md
└── screenshots/              # Test evidence
    ├── login-page.png
    └── checkout-success.png
```

## File Naming Convention

```
QA-YYYYMMDD-###-feature-name.md
```

- `QA` - Prefix for all QA test files
- `YYYYMMDD` - Creation date
- `###` - Sequential number for that day (001, 002, etc.)
- `feature-name` - Kebab-case feature description

**Examples:**
- `QA-20250105-001-user-login.md`
- `QA-20250105-002-password-reset.md`
- `QA-20250106-001-checkout-flow.md`

## Status Lifecycle

```
DRAFT → ACTIVE → EXECUTED → ARCHIVED
```

| Status | Description | Location |
|--------|-------------|----------|
| `DRAFT` | Being written, not ready for execution | `qa-tests/draft/` |
| `ACTIVE` | Ready to be executed by testers | `qa-tests/active/` |
| `EXECUTED` | Has been run, awaiting review/archival | `qa-tests/executed/` |
| `ARCHIVED` | Historical reference, no longer active | `qa-tests/archived/YYYY/` |

### Status Transitions

- **DRAFT → ACTIVE**: All test cases complete, metadata filled, reviewed
- **ACTIVE → EXECUTED**: Test has been run, execution log updated
- **EXECUTED → ARCHIVED**: Test cycle complete, moved to archive
- **Any → DRAFT**: Test needs rework (regression found, requirements changed)

## Required Metadata

Every QA test file MUST include:

```markdown
## Metadata
- **Test ID**: QA-YYYYMMDD-###
- **Feature**: [Feature name]
- **Application**: [App name]
- **URL**: [Test environment URL]
- **Created**: [YYYY-MM-DD]
- **Author**: [Name]
- **Status**: [DRAFT|ACTIVE|EXECUTED|ARCHIVED]
- **Priority**: [Critical|High|Medium|Low]
- **Estimated Time**: [X minutes]
- **PRD Reference**: [Link to PRD section if applicable]
```

## Priority Definitions

| Priority | Description | Execution Frequency |
|----------|-------------|---------------------|
| **Critical** | Core functionality, blocking issues | Every release |
| **High** | Important features, user-facing | Every sprint |
| **Medium** | Secondary features, edge cases | Monthly |
| **Low** | Nice-to-have, rare scenarios | Quarterly |

## PRD Traceability

Link QA tests to PRD requirements:

```markdown
## Requirement Traceability

| Requirement | PRD Section | Test Cases |
|-------------|-------------|------------|
| User can login with email/password | PRD 3.1.1 | TC-001, TC-002 |
| Password must be 8+ characters | PRD 3.1.2 | TC-003 |
| Failed login shows error message | PRD 3.1.3 | EC-001, EC-002 |
```

## Execution Log Format

Track test runs in each test file:

```markdown
## Test Execution Log

| Date | Tester | Environment | Build | Result | Issues |
|------|--------|-------------|-------|--------|--------|
| 2025-01-05 | Jane | staging | v1.2.3 | PASS | None |
| 2025-01-04 | John | staging | v1.2.2 | FAIL | #123 |
```

## Quality Checks Before Activation

Before moving a test from DRAFT to ACTIVE:

- [ ] All test cases have clear steps
- [ ] Expected results are specific and verifiable
- [ ] Prerequisites are documented
- [ ] Test data is specified (not "enter something")
- [ ] Screenshots placeholders identified
- [ ] Priority is assigned
- [ ] Estimated time is realistic
- [ ] PRD traceability added (if applicable)

## Archival Rules

Archive a test when:
- Feature has been deprecated
- Test has been superseded by new test
- Test hasn't been executed in 6+ months
- Feature requirements have fundamentally changed

Archival metadata to add:
```markdown
## Archive Information
- **Archived Date**: [YYYY-MM-DD]
- **Archived By**: [Name]
- **Archive Reason**: [Deprecated|Superseded|Stale|Requirements Changed]
- **Superseded By**: [New test ID, if applicable]
```

## Metrics to Track

When listing or reporting on QA tests:

1. **Coverage**: Tests per feature/PRD
2. **Execution Rate**: % of active tests executed this period
3. **Pass Rate**: % of executed tests that passed
4. **Age**: Days since last execution
5. **Flakiness**: Tests that flip between pass/fail

Related Skills

qa-testing-methodology

9
from jpoutrin/product-forge

QA test design patterns (equivalence partitioning, boundary analysis, accessibility). Auto-loads when designing test cases, planning test coverage, or writing test procedures.

qa-screenshot-management

9
from jpoutrin/product-forge

Screenshot capture, organization, and comparison for QA testing. Use when taking screenshots during test execution to ensure proper naming, organization, and traceability back to test cases.

prd-management

9
from jpoutrin/product-forge

Use when organizing PRDs, tracking requirements, managing product specs, updating PRD status, archiving completed docs, or setting up PRD structure. Auto-applies naming conventions and lifecycle management.

list-qa-tests

9
from jpoutrin/product-forge

List QA test procedures with status and priority

enrich-qa-test

9
from jpoutrin/product-forge

Review QA test and capture element screenshots to enrich documentation

create-qa-test

9
from jpoutrin/product-forge

Create a new QA test procedure for a feature

zod

9
from jpoutrin/product-forge

Zod schema validation patterns and type inference. Auto-loads when validating schemas, parsing data, validating forms, checking types at runtime, or using z.object/z.string/z.infer in TypeScript.

typescript-import-style

9
from jpoutrin/product-forge

Merge-friendly import formatting (one-per-line, alphabetical). Auto-loads when writing TypeScript/JavaScript imports to minimize merge conflicts in parallel development. Enforces consistent grouping and sorting.

setup-mcp-auth

9
from jpoutrin/product-forge

Configure authentication for an existing FastMCP server

fastmcp

9
from jpoutrin/product-forge

FastMCP TypeScript framework patterns for MCP servers. Auto-loads when building MCP servers, creating tools/resources/prompts, implementing authentication, configuring transports, or working with FastMCP in TypeScript.

add-mcp-tool

9
from jpoutrin/product-forge

Add a new tool to an existing FastMCP server with guided configuration

add-mcp-resource

9
from jpoutrin/product-forge

Add a new resource or resource template to an existing FastMCP server