L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Design et création · SKILL.md

qa-manual-istqb

qa-manual-istqb

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, regres…

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

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

RequirementNotes
Node.js 18+Required for CLI script and Playwright
Playwrightnpm init playwright@latest for automation
Text editorFor creating/editing markdown and CSV artifacts
GitRecommended 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:

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

ProblemCauseSolution
Test cases lack traceabilityMissing requirement IDsAdd requirement_id column; link to user stories/ACs
Bug reports get rejectedInsufficient reproduction stepsUse minimal steps; include exact data and environment
Regression suite too slowToo many tests, no prioritizationApply risk-based selection; tier into smoke/sanity/full
Flaky automated testsUnstable locators or timingUse data-testid; avoid sleeps; use Playwright auto-waits
Test estimates are wrongScope creep, missing risksAdd contingency; re-estimate when scope changes
Reviews find no defectsSuperficial reviewUse checklists; allocate sufficient time; rotate reviewers
Unclear test oraclesMissing expected resultsDefine oracles from requirements, rules, or reference systems

Bundled Resources

Templates (templates/)

TemplatePurpose
test-plan.mdISTQB-aligned test plan structure
test-summary-report.mdEnd-of-cycle summary and sign-off
test-cases.csvTest case repository with traceability
test-conditions.mdTest conditions derived from test basis
traceability-matrix.csvRequirements ↔ tests ↔ defects mapping
bug-report.mdDetailed defect report
bug-log.csvDefect tracking log
regression-suite.mdSuite definition and selection rules
exploratory-charter.mdSession-based exploratory testing
playwright-spec.tsPlaywright test scaffold
test-environment-checklist.mdEnvironment readiness verification
risk-assessment-matrix.mdQuality risk identification and prioritization

References (references/)

ReferenceContent
test-design-techniques.mdEP, BVA, decision tables, state transitions, use cases
experience-based-techniques.mdError guessing, checklist-based, exploratory
static-testing.mdReviews, walkthroughs, inspections
test-levels-types.mdUnit, integration, system, acceptance; functional, non-functional
test-estimation.mdEstimation techniques and factors
test-monitoring-metrics.mdProgress tracking and quality metrics
risk-based-testing.mdRisk identification, analysis, mitigation
istqb-glossary.mdKey ISTQB terminology
test-process-and-deliverables.mdTest process phases and outputs
automation-playwright-best-practices.mdPlaywright implementation guidance
regression-suite-strategy.mdSuite management and optimization
bug-report-quality.mdEffective defect reporting
defect-lifecycle.mdDefect states and workflow

Scripts (scripts/)

ScriptPurpose
qa_artifacts.mjsCLI 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
Skills enregistrées