bmad-method-test-architecture-enterprise

Test Architect (TEA)

TEA (Test Engineering Architect) is a standalone BMAD module that delivers risk-based test strategy, test automation guidance, and release gate decisions. It provides a single expert agent (Murat, Master Test Architect and Quality Advisor) and nine workflows spanning Teach Me Testing (TEA Academy), framework setup, test design, ATDD, automation, traceability, NFR assessment, CI guidance, and test review.

Docs: https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/

Why TEA

• Risk-based testing with measurable quality gates
• Consistent, knowledge-base driven outputs
• Clear prioritization (P0-P3) and traceability
• Optional Playwright Utils, CLI, and MCP browser automation

How BMad Works

BMad works because it turns big, fuzzy work into repeatable workflows. Each workflow is broken into small steps with clear instructions, so the AI follows the same path every time. It also uses a shared knowledge base (standards and patterns) so outputs are consistent, not random. In short: structured steps + shared standards = reliable results.

How TEA Fits In

TEA plugs into BMad the same way a specialist plugs into a team. It uses the same step‑by‑step workflow engine and shared standards, but focuses exclusively on testing and quality gates. That means you get a risk‑based test plan, automation guidance, and go/no‑go decisions that align with the rest of the BMad process.

Architecture & Flow

BMad is a small agent + workflow engine. There is no external orchestrator — everything runs inside the LLM context window through structured instructions.

Building Blocks

Each workflow directory contains these files, and each has a specific job:

File	What it does	When it loads
SKILL.md	Expert persona — identity, principles, critical actions, capabilities table	First — always in context
workflow.yaml	Machine-readable metadata — config variables, required tools, tags	Second — resolves {project-root}, {config_source}, {test_artifacts}
workflow.md	Human-readable entry point — goals, mode menu (Create/Edit/Validate), routes to first step	Second — presents mode choice
instructions.md	Workflow-specific rules and context (optional, supplements workflow.md)	On demand
steps-c/*.md	Create steps — primary execution, 5-9 sequential files	One at a time (just-in-time)
steps-e/*.md	Edit steps — always 2 files: assess target, apply edit	One at a time
steps-v/*.md	Validate steps — always 1 file: evaluate against checklist	On demand
checklist.md	Validation criteria — what "done" looks like for this workflow	Read by steps-v
*-template.md	Output skeleton with {PLACEHOLDER} vars — steps fill these in to produce the final artifact	Read by steps-c when generating output
tea-index.csv	Knowledge fragment index — id, name, tags, tier (core/extended/specialized), file path	Read by step-01 to decide which fragments to load
knowledge/*.md	40 reusable fragments — standards, patterns, API references (e.g., data-factories.md, pactjs-utils-overview.md)	Selectively read into context based on tier + config flags

flowchart LR
  U[User] --> A[Agent Persona]
  A --> W[Workflow Entry: workflow.md]
  W --> S[Step Files: steps-c / steps-e / steps-v]
  S --> K[Knowledge Fragments<br/>tea-index.csv → knowledge/*.md]
  S --> T[Templates & Checklists<br/>*-template.md, checklist.md]
  S --> O[Outputs: docs/tests/reports<br/>when a step writes output]
  O --> V[Validation: checklist + report]

How It Works at Runtime