Files
BMAD-METHOD/docs/tea/how-to/workflows/run-test-design.md
Alex Verkhovsky 91f6c41be1 docs: radical reduction of documentation scope for v6 beta (#1406)
* docs: radical reduction of documentation scope for v6 beta

Archive and basement unreviewed content to ship a focused, minimal doc set.

Changes:
- Archive stale how-to workflow guides (will rewrite for v6)
- Archive outdated explanation and reference content
- Move unreviewed content to basement for later review
- Reorganize TEA docs into dedicated /tea/ section
- Add workflow-map visual reference page
- Simplify getting-started tutorial and sidebar navigation
- Add explanation pages: brainstorming, adversarial-review, party-mode,
  quick-flow, advanced-elicitation
- Fix base URL handling for subdirectory deployments (GitHub Pages forks)

The goal is a minimal, accurate doc set for beta rather than
comprehensive but potentially misleading content.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* refactor: restructure BMM and agents documentation by consolidating and flattening index files.

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-25 14:00:26 -06:00

4.5 KiB

title, description
title description
How to Run Test Design with TEA How to create comprehensive test plans using TEA's test-design workflow

Use TEA's test-design workflow to create comprehensive test plans with risk assessment and coverage strategies.

When to Use This

System-level (Phase 3):

  • After architecture is complete
  • Before implementation-readiness gate
  • To validate architecture testability

Epic-level (Phase 4):

  • At the start of each epic
  • Before implementing stories in the epic
  • To identify epic-specific testing needs

:::note[Prerequisites]

  • BMad Method installed
  • TEA agent available
  • For system-level: Architecture document complete
  • For epic-level: Epic defined with stories :::

Steps

1. Load the TEA Agent

Start a fresh chat and load the TEA (Test Architect) agent.

2. Run the Test Design Workflow

test-design

3. Specify the Mode

TEA will ask if you want:

  • System-level — For architecture testability review (Phase 3)
  • Epic-level — For epic-specific test planning (Phase 4)

4. Provide Context

For system-level:

  • Point to your architecture document
  • Reference any ADRs (Architecture Decision Records)

For epic-level:

  • Specify which epic you're planning
  • Reference the epic file with stories

5. Review the Output

TEA generates test design document(s) based on mode.

What You Get

System-Level Output (TWO Documents):

TEA produces two focused documents for system-level mode:

  1. test-design-architecture.md (for Architecture/Dev teams)

    • Purpose: Architectural concerns, testability gaps, NFR requirements
    • Quick Guide with 🚨 BLOCKERS / ⚠️ HIGH PRIORITY / 📋 INFO ONLY
    • Risk assessment (high/medium/low-priority with scoring)
    • Testability concerns and architectural gaps
    • Risk mitigation plans for high-priority risks (≥6)
    • Assumptions and dependencies
  2. test-design-qa.md (for QA team)

    • Purpose: Test execution recipe, coverage plan, Sprint 0 setup
    • Quick Reference for QA (Before You Start, Execution Order, Need Help)
    • System architecture summary
    • Test environment requirements (moved up - early in doc)
    • Testability assessment (prerequisites checklist)
    • Test levels strategy (unit/integration/E2E split)
    • Test coverage plan (P0/P1/P2/P3 with detailed scenarios + checkboxes)
    • Sprint 0 setup requirements (blockers, infrastructure, environments)
    • NFR readiness summary

Why Two Documents?

  • Architecture teams can scan blockers in <5 min (Quick Guide format)
  • QA teams have actionable test recipes (step-by-step with checklists)
  • No redundancy between documents (cross-references instead of duplication)
  • Clear separation of concerns (what to deliver vs how to test)

Epic-Level Output (ONE Document):

test-design-epic-N.md (combined risk assessment + test plan)

  • Risk assessment for the epic
  • Test priorities (P0-P3)
  • Coverage plan
  • Regression hotspots (for brownfield)
  • Integration risks
  • Mitigation strategies

Test Design for Different Tracks

Track Phase 3 Focus Phase 4 Focus
Greenfield System-level testability review Per-epic risk assessment and test plan
Brownfield System-level + existing test baseline Regression hotspots, integration risks
Enterprise Compliance-aware testability Security/performance/compliance focus

Examples

System-Level (Two Documents):

  • cluster-search/cluster-search-test-design-architecture.md - Architecture doc with Quick Guide
  • cluster-search/cluster-search-test-design-qa.md - QA doc with test scenarios

Key Pattern:

  • Architecture doc: "ASR-1: OAuth 2.1 required (see QA doc for 12 test scenarios)"
  • QA doc: "OAuth tests: 12 P0 scenarios (see Architecture doc R-001 for risk details)"
  • No duplication, just cross-references

Tips

  • Run system-level right after architecture — Early testability review
  • Run epic-level at the start of each epic — Targeted test planning
  • Update if ADRs change — Keep test design aligned
  • Use output to guide other workflows — Feeds into atdd and automate
  • Architecture teams review Architecture doc — Focus on blockers and mitigation plans
  • QA teams use QA doc as implementation guide — Follow test scenarios and Sprint 0 checklist

Next Steps

After test design:

  1. Setup Test Framework — If not already configured
  2. Implementation Readiness — System-level feeds into gate check
  3. Story Implementation — Epic-level guides testing during dev