BMAD Method lessons for QA.

Lifecycle, Agents, Workflows, and Artifacts

BMAD organizes work through specialized agents and named workflows. QA value comes from the artifact chain and review boundaries, not from agent role-play alone.

Treat each BMAD agent as a responsibility lens with a defined input and output. Product artifacts establish user and business intent. Architecture artifacts expose constraints and quality attributes. Stories make the work implementable. QA artifacts challenge risk, design coverage, and collect evidence.

The method helps keep context and sequence visible, but generated handoffs can still drift. Put stable requirement, story, risk, and test IDs in artifacts. Review every transition against the owned source rather than trusting that two agents shared the same interpretation.

Install BMAD V6 and Inspect the Workspace

Install the current method in a disposable repository, review generated content before committing it, and record the exact version used for training.

The current BMAD repository documents Node.js 20.12 or newer, Python 3.10 or newer, and uv as prerequisites. Run the installer from the target project, choose only the modules your engagement needs, and inspect every generated file before adding it to source control.

Agent commands and host integrations can evolve. Use the generated help and official documentation for the installed version instead of copying an old slash-command list. The course names workflows by their documented purpose so the operating model survives UI changes.

node --version
python3 --version
uv --version

mkdir bmad-qa-capstone
cd bmad-qa-capstone
git init
npx bmad-method install

git status --short
git diff --no-index /dev/null <generated-file-to-review>

Installation review

• Record the installer and module versions.
• Review generated agent, workflow, template, and configuration files.
• Keep credentials and production environment values outside generated content.
• Commit a clean baseline before running the first workflow.
• Document how another learner can uninstall or restore the exercise.

Requirements, Architecture, Stories, and QA Handoffs

A QA handoff is complete when intent, design constraints, acceptance, data, observability, and ownership survive the transition into executable work.

Use IDs across the product requirement, architecture decision, story acceptance criteria, risk item, and test. The ID is a navigation aid; reviewers must still confirm that meaning remains consistent. A story can quote a requirement while accidentally narrowing its boundary or removing an NFR.

For login lockout, architecture must expose a controllable clock, account-isolated state, public response, and audit event. The story must name threshold and recovery boundaries. QA should reject a handoff that can only be verified through private implementation fields or a manual screenshot.

{
  "epic": "AUTH-E01",
  "story": "AUTH-S04",
  "requirements": ["AUTH-LOCK-01", "AUTH-LOCK-02", "AUTH-LOCK-03"],
  "architecture": ["ADR-017"],
  "risks": ["SEC-P0-03", "REL-P1-02"],
  "evidenceOwners": {
    "functional": "SDET",
    "security": "Security reviewer",
    "release": "QA lead"
  }
}

Built-In QA Versus Test Architect Enterprise

BMAD offers a fast built-in E2E generation workflow and a deeper Test Architect Enterprise module. Choose by risk and evidence needs, not by novelty.

The built-in bmad-qa-generate-e2e-tests workflow detects the framework, identifies features, creates API and E2E tests, then runs and verifies them. It is useful for standard coverage with established requirements and architecture.

TEA adds a test-architecture operating model: risk-based test design, framework and CI setup, ATDD, automation, quality review, NFR evidence, traceability, and gate decisions. Use it when criticality, scale, compliance, brownfield uncertainty, or release governance needs more than generated E2E tests.

TEA's named workflows

• Teach Me Testing, Test Design, Test Framework, and CI Setup.
• ATDD, Test Automation, and Test Review with a 0-100 quality score.
• NFR Evidence Audit and Traceability with a gate recommendation.

P0-P3 Risk Assessment and Test Design

TEA test design allocates evidence according to business impact and likelihood. Priority controls depth and timing; it does not promise zero risk.

Build a risk register with a stable ID, impacted quality attribute, likelihood, impact, detection difficulty, owner, mitigation, and required evidence. Assign P0 to release-critical paths that need the earliest and strongest coverage; use P1-P3 for progressively lower urgency based on the project's agreed model.

Test at the lowest layer that can provide a trustworthy oracle, then add cross-layer evidence for critical journeys. A P0 lockout rule may need model/unit boundary tests, API properties, E2E privacy checks, security review, and observability evidence. It does not need every permutation at the slowest UI layer.

Design output

• Risk register with rationale and owners.
• Coverage map by level, environment, and data need.
• Entry and exit criteria for critical evidence.
• Known gaps, accepted residual risk, and review date.

Test Framework and CI Setup

A test framework is a product with contracts for identity, fixtures, data, isolation, reporting, retries, and CI execution.

Use the TEA Test Framework workflow to establish the repository structure and conventions before multiplying tests. Define stable test identity, environment configuration, synthetic data factories, clock control, cleanup, reporter outputs, and secret handling. Prove the framework with a small vertical slice.

CI Setup should separate fast pull-request gates from scheduled or environment-heavy suites. Preserve reports and traces with the commit SHA. Make retries visible and diagnostic; do not let a retry convert an unstable critical test into an unqualified green gate.

npm ci
npm run lint
npx tsc --noEmit
npx playwright test tests/auth/lockout.api.spec.ts --project=api
npx playwright test tests/auth/lockout.e2e.spec.ts --project=chromium
npx playwright show-report

ATDD Before Implementation

ATDD turns accepted behavior and risk into executable examples before code, giving implementation a visible target and QA a preserved red-to-green proof.

Use the TEA ATDD workflow after requirements and test design are reviewed. Select P0 and P1 acceptance behavior, create failing tests or executable examples, and confirm the failure is for the intended missing behavior. Avoid asserting private implementation details that lock the design unnecessarily.

The implementation team and QA review examples together. Data, clock, and state setup belong in the test harness. A failing ATDD test is valuable only when it distinguishes the absent behavior from environment or fixture defects.

test("AUTH-LOCK-01 rejects the sixth attempt during lock", async ({ request }) => {
  const account = await createSyntheticAccount();
  await failPassword(request, account, 5);

  const response = await attemptLogin(request, account, account.validPassword);

  expect(response.status()).toBe(401);
  expect(await response.json()).toMatchObject({
    message: "Invalid email or password",
  });
  expect(await readSession(account)).toBeNull();
});

1. Link the example to requirement and risk IDs.
2. Run it against the pre-implementation baseline and classify the failure.
3. Freeze data and time dependencies so red is reproducible.
4. Protect the observable assertions during implementation.
5. Preserve baseline and accepted reports with their commits.

Test Automation and 0-100 Review

TEA separates creating automation from reviewing its quality. The review score organizes findings; it does not replace judgment or release gates.

Use Test Automation to expand approved design and ATDD coverage with framework conventions, stable data, and the right test layer. Then use Test Review to evaluate readability, isolation, determinism, assertions, maintainability, performance, and risk coverage on a 0-100 scale.

Inspect the actual code and execution evidence. A high score cannot excuse a missing P0 requirement, leaked credential, disabled assertion, or nonreproducible environment. Record blockers separately from weighted quality observations.

qualityScore: 84
blockers:
  - "SEC-P0-03 has no cross-account isolation property test"
findings:
  - id: QA-REV-12
    severity: high
    path: tests/auth/lockout.e2e.spec.ts
    issue: "Global retry hides intermittent lock-state race"
decision: "Revise before trace gate"

NFR Evidence for Performance, Security, and Reliability

NFR claims need thresholds, environments, methods, raw evidence, owners, and limits. A functional green suite cannot imply nonfunctional readiness.

Use the TEA NFR Evidence Audit to inventory required quality attributes and the evidence that supports each. For authentication, include brute-force protection, response privacy, audit completeness, latency under attack-shaped load, recovery, and counter consistency across replicas.

Record environment parity, data volume, tool versions, configuration, time window, raw artifact location, and known blind spots. Mark a claim unsupported when evidence is absent or stale. Do not generate a confident narrative to fill the gap.

Traceability and PASS, CONCERNS, FAIL, or WAIVED Gates

The TEA trace workflow connects requirements and risks to tests and evidence, then produces an explicit gate recommendation with accountable exceptions.

Build the matrix from stable IDs and current evidence. For every P0/P1 item, show the test level, latest result, environment, report, unresolved defect, and owner. Evaluate both coverage completeness and evidence quality; a linked test that never ran is not covered for release.

Use PASS when required evidence satisfies the agreed gate with no blocking gaps. Use CONCERNS when residual issues are visible but not automatically blocking. Use FAIL for unmet blocking criteria. Use WAIVED only when an authorized owner accepts a specific exception with scope and expiry.

gate: CONCERNS
commit: <git-sha>
environment: staging-2026-07-15
coveredP0: 4/4
coveredP1: 6/7
residualRisk:
  id: REL-P1-02
  gap: "Multi-region counter consistency not exercised"
  mitigation: "Single-region release plus metric alert"
  owner: "Platform lead"
  reviewBy: "2026-07-22"
decisionOwner: "QA lead"

Greenfield, Brownfield, and TEA Lite Engagements

TEA supports different engagement depths. Match the workflow to lifecycle timing, existing debt, regulatory needs, and team capacity.

Greenfield work can design testability, ATDD, framework, and CI before implementation scales. Brownfield work begins with discovery: current architecture, flaky suites, data dependencies, incident history, and missing traceability. TEA Lite applies focused risk design and gates without adopting every workflow.

A standalone engagement can audit or improve a specific area. An integrated engagement keeps test architecture connected throughout product and delivery work. Enterprise adoption adds governance and reuse, but should not force every low-risk change through the same artifact depth.

Capstone: Carry One Login Epic Through TEA

Complete a compact TEA lifecycle for a synthetic login and lockout epic, ending with reproducible evidence and an explicit gate decision.

The capstone covers valid login, generic invalid-credential handling, account-isolated lockout after five failures, recovery after fifteen minutes, and audit events. Product and security owners approve policy values before test design. The environment exposes a frozen clock and synthetic reset path.

Use TEA Lite depth but execute every selected workflow honestly: test design, framework/CI check, ATDD, automation, review, NFR audit, and trace gate. Preserve artifacts with stable IDs and the commit that produced the reports.

docs/qa/auth-lockout/
  risk-register.md
  test-design.md
  atdd-baseline.md
  automation-review.md
  nfr-evidence.md
  traceability.csv
  gate-decision.md
tests/auth/
  login.api.spec.ts
  lockout.property.spec.ts
  lockout.e2e.spec.ts
artifacts/auth-lockout/<commit-sha>/

Exit criteria

1. All P0 risks have owned, current, reproducible evidence.
2. ATDD baseline proves the critical test detected missing behavior.
3. Automation review has no unresolved blocker and documents its score.
4. NFR audit labels every claim supported, limited, or missing.
5. Traceability identifies current reports, environment, defects, and owners.
6. The gate is PASS, CONCERNS, FAIL, or WAIVED with a named decision owner.