---
name: qa-manual-istqb
description: 'Create QA artifacts from requirements: test plans, test conditions/cases, bug reports, regression suites, traceability, and exploratory charters. Use for test planning, test design, defects, coverage, or QA deliverables. Applies ISTQB risk-based techniques and loads templates only when needed. Keywords: test plan, test case, bug report, traceability, regression suite, QA artifact.'
license: 'Complete terms in LICENSE.txt'
---

# QA Test Design & ISTQB Artifacts

Complete ISTQB Foundation Level (CTFL) aligned workflow for QA test engineers covering:
**Test Planning → Test Analysis → Test Design → Test Implementation → Test Execution → Test Completion**

## When to Use This Skill

- Drafting ready-to-fill QA deliverables from requirements, user stories, or acceptance criteria
- Creating or reviewing **test plans** and **test strategies**
- Generating **test conditions** and **test cases** from requirements
- Applying **test design techniques** (EP, BVA, decision tables, state transitions, use cases)
- Writing **bug reports** and managing **defect lifecycle**
- Building **regression suites** with risk-based selection
- Creating **traceability matrices** (requirements ↔ tests ↔ defects)
- Conducting **exploratory testing** sessions with charters
- Estimating test effort using ISTQB techniques
- Reviewing testware through **static testing** practices
- Selecting automation candidates and preparing traceable Playwright scaffolds

### Do NOT Use For

- Authoring/maintaining versioned Playwright spec code (use `playwright-e2e-testing`).
- Selenium/Java test authoring (use `webapp-selenium-testing`).
- Driving a live browser to debug (use `playwright-cli`) or governing an existing regression suite's CI (use `playwright-regression-testing`).
- Adversarial strategy critique — that is the `grill-me-qa` skill's purpose; this skill produces artifacts, it does not interrogate them.

## Prerequisites

| Requirement | Notes                                           |
| ----------- | ----------------------------------------------- |
| Node.js 18+ | Required for CLI script and Playwright          |
| Playwright  | `npm init playwright@latest` for automation     |
| Text editor | For creating/editing markdown and CSV artifacts |
| Git         | Recommended for testware version control        |

## Quick Start (choose one)

- Create a test plan: use `templates/test-plan.md` as a starting point.
- Create a test summary report: use `templates/test-summary-report.md`.
- Generate test cases: use `templates/test-cases.csv` and fill it from the test basis (requirements, user stories, acceptance criteria).
- Create a bug report: use `templates/bug-report.md`.
- Create a bug log: use `templates/bug-log.csv`.
- Create traceability: use `templates/traceability-matrix.csv`.
- Build a regression suite definition: use `templates/regression-suite.md`.
- Scaffold Playwright tests: use `templates/playwright-spec.ts` and adapt to the system under test.
- Run exploratory testing: use `templates/exploratory-charter.md` to timebox and capture outcomes.

If running locally, generate artifacts with the bundled CLI:

```bash
node scripts/qa_artifacts.mjs list
node scripts/qa_artifacts.mjs create test-plan --out specs --project "My App" --release "R1"
node scripts/qa_artifacts.mjs create test-cases --out specs --feature "Checkout"
node scripts/qa_artifacts.mjs create bug-report --out specs/bugs --title "Search returns 500"
```

## Inputs to collect (ask if missing)

- **Test basis**: requirements, user stories, acceptance criteria, designs, risk register, defect history.
- **Scope**: in-scope/out-of-scope features, target platforms/browsers/devices, locales, accessibility, integrations.
- **Quality risks**: what can fail, impact, likelihood, regulatory/compliance, critical user journeys.
- **Constraints**: deadlines, environments, data availability, tooling, access/roles, CI/CD expectations.
- **Definitions**: severity vs priority scale, test levels and test types to cover, entry/exit criteria.

## Workflows

### 1) Create a test plan (and/or test strategy)

1. Identify test objectives, scope, assumptions, and constraints from the test basis.
2. Define test levels and types (functional + change-related + key non-functional, as applicable).
3. Choose test design techniques per area (see `references/test-design-techniques.md`).
4. Specify environments, test data, tooling, and configuration management needs.
5. Define entry/exit criteria, deliverables, and reporting cadence/metrics.
6. Add a risk matrix and mitigation actions; prioritize testing accordingly (risk-based testing).

Use: `templates/test-plan.md` (detailed sections + checklists).

### 2) Generate test conditions and test cases

1. Convert the test basis into **test conditions** (what to test) before writing step-by-step cases.
2. For each condition, pick a technique:
   - Equivalence partitions and boundary values for inputs/validation.
   - Decision tables for rule combinations.
   - State transitions for lifecycle/flows.
   - Use-case/scenario tests for end-to-end journeys.
   - Exploratory testing sessions to learn quickly (see `templates/exploratory-charter.md`).
3. Write test cases that are atomic, unambiguous, and traceable to requirement/user story IDs.
4. Add expected results that are observable and measurable (define the test oracle).
5. Add priority and risk tags to support risk-based regression selection.
6. Mark automation candidates using stability + value criteria (see `references/automation-playwright-best-practices.md`).

Use: `templates/test-cases.csv`.

### 3) Prepare automation candidates and Playwright scaffolds

1. Select candidates using stability, value, and risk criteria (see `references/automation-playwright-best-practices.md`).
2. Create a traceable scaffold from `templates/playwright-spec.ts`, including the test case ID and suite tags.
3. Use `playwright-e2e-testing` to implement and maintain the versioned UI spec, fixtures, and test infrastructure.

### 4) Build and maintain regression suites

1. Define suite tiers (example): smoke (critical paths), sanity (build verification), regression (broad), full (release).
2. Select tests using risk + frequency + criticality + defect history (not only coverage).
3. Tag tests consistently and document selection rules and ownership.
4. Review the suite regularly: remove obsolete coverage, add coverage for escaped defects and high-risk changes.

Use: `templates/regression-suite.md` and `references/regression-suite-strategy.md`.

### 5) Create bug reports and document bugs effectively

1. Reproduce reliably; reduce to minimal steps; note variability (frequency) and scope.
2. Capture environment details (build/app version, OS, browser/device, account/role, data conditions).
3. Describe expected vs actual behavior; include impact; set severity and priority consistently.
4. Attach evidence (screenshots, console logs, network traces, Playwright trace) and link related tests/requirements.
5. Track lifecycle: triage notes, owner, fix version, verification steps and results, closure criteria.

Use: `templates/bug-report.md` and `references/bug-report-quality.md`.

### 6) Conduct static testing (reviews)

1. Schedule reviews early (shift-left): requirements, designs, test plans, test cases.
2. Use checklists for consistency (see `references/static-testing.md`).
3. Document findings with severity and actionability.
4. Track defects found in static testing separately (prevention vs detection).

Use: `references/static-testing.md` for review checklists and techniques.

### 7) Estimate test effort

1. Identify factors: scope, complexity, risk, team experience, tool maturity.
2. Apply estimation techniques (see `references/test-estimation.md`):
   - Expert judgment / historical data
   - Test point analysis
   - Work breakdown structure
3. Add contingency for risks and unknowns.
4. Review and refine estimates as the project progresses.

Use: `references/test-estimation.md` for techniques and formulas.

### 8) Monitor test progress and metrics

1. Track execution metrics: planned vs executed vs passed vs failed vs blocked.
2. Monitor defect metrics: found vs fixed vs open, by severity/priority.
3. Calculate test coverage: requirements covered, risk areas tested.
4. Report status regularly and escalate blockers early.

Use: `references/test-monitoring-metrics.md` for metrics definitions and dashboards.

## Quality Gates (self-check)

- **Test plan** includes scope, approach, risks, environments, entry/exit criteria, deliverables, and metrics.
- **Test cases** are traceable, atomic, deterministic, and include clear oracles and data.
- **Automation** is maintainable (stable locators, minimal flake, independent tests, clear assertions).
- **Regression** is risk-based, tagged, and curated with clear add/remove rules.
- **Bug reports** are reproducible, actionable, and contain evidence + environment + impact.
- **Static testing** reviews are documented with findings tracked to resolution.
- **Estimates** include contingency and are refined as scope clarifies.

## Troubleshooting

| Problem                      | Cause                             | Solution                                                      |
| ---------------------------- | --------------------------------- | ------------------------------------------------------------- |
| Test cases lack traceability | Missing requirement IDs           | Add `requirement_id` column; link to user stories/ACs         |
| Bug reports get rejected     | Insufficient reproduction steps   | Use minimal steps; include exact data and environment         |
| Regression suite too slow    | Too many tests, no prioritization | Apply risk-based selection; tier into smoke/sanity/full       |
| Flaky automated tests        | Unstable locators or timing       | Use `data-testid`; avoid sleeps; use Playwright auto-waits    |
| Test estimates are wrong     | Scope creep, missing risks        | Add contingency; re-estimate when scope changes               |
| Reviews find no defects      | Superficial review                | Use checklists; allocate sufficient time; rotate reviewers    |
| Unclear test oracles         | Missing expected results          | Define oracles from requirements, rules, or reference systems |

## Bundled Resources

### Templates (`templates/`)

| Template                        | Purpose                                        |
| ------------------------------- | ---------------------------------------------- |
| `test-plan.md`                  | ISTQB-aligned test plan structure              |
| `test-summary-report.md`        | End-of-cycle summary and sign-off              |
| `test-cases.csv`                | Test case repository with traceability         |
| `test-conditions.md`            | Test conditions derived from test basis        |
| `traceability-matrix.csv`       | Requirements ↔ tests ↔ defects mapping         |
| `bug-report.md`                 | Detailed defect report                         |
| `bug-log.csv`                   | Defect tracking log                            |
| `regression-suite.md`           | Suite definition and selection rules           |
| `exploratory-charter.md`        | Session-based exploratory testing              |
| `playwright-spec.ts`            | Playwright test scaffold                       |
| `test-environment-checklist.md` | Environment readiness verification             |
| `risk-assessment-matrix.md`     | Quality risk identification and prioritization |

### References (`references/`)

| Reference                                 | Content                                                           |
| ----------------------------------------- | ----------------------------------------------------------------- |
| `test-design-techniques.md`               | EP, BVA, decision tables, state transitions, use cases            |
| `experience-based-techniques.md`          | Error guessing, checklist-based, exploratory                      |
| `static-testing.md`                       | Reviews, walkthroughs, inspections                                |
| `test-levels-types.md`                    | Unit, integration, system, acceptance; functional, non-functional |
| `test-estimation.md`                      | Estimation techniques and factors                                 |
| `test-monitoring-metrics.md`              | Progress tracking and quality metrics                             |
| `risk-based-testing.md`                   | Risk identification, analysis, mitigation                         |
| `istqb-glossary.md`                       | Key ISTQB terminology                                             |
| `test-process-and-deliverables.md`        | Test process phases and outputs                                   |
| `automation-playwright-best-practices.md` | Playwright implementation guidance                                |
| `regression-suite-strategy.md`            | Suite management and optimization                                 |
| `bug-report-quality.md`                   | Effective defect reporting                                        |
| `defect-lifecycle.md`                     | Defect states and workflow                                        |

### Scripts (`scripts/`)

| Script             | Purpose                                          |
| ------------------ | ------------------------------------------------ |
| `qa_artifacts.mjs` | CLI tool to generate QA artifacts from templates |

---

## Red Flags

- Generating test cases with no link back to a requirement or risk — untraceable coverage is theatre.
- Bug reports missing repro steps, expected vs actual, or environment — unusable for developers.
- Regression suites selected by gut feel instead of risk/change analysis — wasted effort and missed regressions.
- Test plans with no entry/exit criteria or effort estimate — execution cannot be governed.
- Confusing this artifact-producing skill with strategy critique (use `grill-me-qa` for adversarial review).

---

## Verification

- [ ] **Test cases follow ISTQB structure** — Each case has: ID, description, preconditions, steps, expected result (actual result populated after execution)
- [ ] **Coverage matrix maintained** — Requirements mapped to test cases; no uncovered requirements
- [ ] **Traceability maintained** — Each test case links to a requirement or user story