QA Manual Istqb

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

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:

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.