Test Architect (TEA): AI-Driven Testing That Doesn't Rot

Part 5 of the BMAD-Method series

We've covered the core framework, workflows, custom agents with BMad Builder, and the Creative Intelligence Suite. There's one piece of the BMAD ecosystem we haven't touched yet, and it solves the problem I hear about most from teams using AI for development: the tests are garbage.

Not "they don't run" garbage. They run fine. They pass. They look reasonable in a PR review. Then three sprints later, half of them are flaky, a quarter test implementation details instead of behavior, and nobody trusts the suite enough to block a deploy on it. The tests rotted — not because anyone wrote bad code, but because the AI that generated them had no testing strategy. It just wrote assertions that matched the current behavior.

TEA (Test Engineering Architect) is BMAD's answer to that problem. It's a module that brings the same structured, workflow-driven approach we use for product management and architecture to the testing side. Nine workflows covering everything from risk-based test planning to release gate decisions.

The Problem TEA Solves

Ask any AI coding tool to "write tests for this component" and you'll get tests. Lots of tests. They'll have descriptive names, reasonable assertions, and they'll pass on the first run. Ship it, right?

Here's what goes wrong. The AI doesn't know which parts of your system are high-risk and need deep coverage versus which parts are stable and need a smoke test. It doesn't know that your checkout flow handles real money and needs different test rigor than your settings page. It doesn't build fixtures that compose cleanly or follow network-first patterns that eliminate flakiness. It just generates test code that looks like test code.

TEA's thesis is that testing is an engineering discipline, not a code generation task. Before you write a single test, you should know what's risky, what the priorities are, and what "good enough" coverage looks like for this specific feature. TEA provides that structure through a knowledge base of testing patterns and a set of workflows that guide you from planning through execution to release decisions.

What TEA Actually Is

TEA is a BMAD module — you install it the same way you install any other BMAD component. It adds a specialized agent persona (Murat, the Test Architect) and nine workflows that cover the full testing lifecycle.

The workflows span BMAD's phases:

Phase 3 (Solutioning) — system-level test design, framework scaffolding, CI pipeline setup. This is where you answer "how do we test this system?" before anyone writes implementation code.

Phase 4 (Implementation) — per-epic test design, ATDD (writing failing tests before code), test automation, test review, and traceability. This is where tests get written, reviewed, and mapped to requirements.

Release Gate — NFR assessment and the trace workflow's gate decision (PASS / CONCERNS / FAIL / WAIVED). This is where you decide whether the build ships.

The Nine Workflows

Here's what each one does and when you'd use it:

Two workflows deserve special attention.

Test Design is the backbone. It produces a risk assessment using probability × impact scoring, then generates a prioritized test plan. P0 items are critical path — if these fail, users can't use the product. P3 items are edge cases that matter but won't block a release. This prioritization is what prevents the "generate 200 tests and hope for the best" approach. You know exactly where to invest testing effort.

Trace is the closer. It's a two-phase workflow: Phase 1 builds a traceability matrix mapping tests to requirements, and Phase 2 makes a gate decision. The gate isn't just "did the tests pass" — it evaluates coverage gaps, risk areas without tests, and NFR compliance. The output is a YAML artifact you can attach to your release process.

Getting Started: Zero to Passing Tests in 30 Minutes

TEA has five engagement models — you don't have to go all-in. Here's the fastest path.

Install

npx bmad-method install
# Select: Test Architect (TEA)

Load the Agent

In your AI coding tool (Claude Code, Cursor, Windsurf, etc.):

bmad-tea

This loads the TEA agent with its menu of workflows.

Scaffold Your Test Framework

framework

TEA asks about your stack (React? Node? What test runner?) and generates a production-ready Playwright or Cypress scaffold — config, directory structure, fixtures, .env.example, the works. Not a toy starter template. The generated structure follows TEA's knowledge base patterns for fixture architecture and network-first testing.

Create a Test Design

test-design

Tell TEA what you're testing and it produces a risk assessment with P0–P3 priorities. For a TodoMVC-style app, the output might flag "creating and displaying todos" as P0 (critical path) and "clearing completed todos" as P2 (medium value). Each priority level gets specific test scenarios.

Generate Tests

automate

Point it at your test design document and TEA generates tests that follow the priorities. P0 scenarios get thorough coverage. P3 scenarios get a smoke test. The generated code uses the fixture patterns from TEA's knowledge base — composable fixtures, network interception before navigation, explicit assertions instead of snapshot comparisons.

Run

npx playwright test

That's the TEA Lite path. You used three workflows (framework, test-design, automate), and you have a test suite that was designed before it was generated. The risk assessment stays with the project as documentation — when someone asks "why do we test X but not Y?" the test design document has the answer.

How TEA Fits Into Full BMAD Projects

If you're running the full BMAD workflow (Parts 1–4 of this series), TEA plugs into specific phases:

After your architect produces the architecture and ADRs in Phase 3, run test-design in system-level mode. This produces two documents: one for the architecture team (testability gaps, ASR validation) and one for QA (test execution recipe, coverage plan, Sprint 0 setup). Both feed into the implementation-readiness gate.

During Phase 4, each epic gets its own test-design run. Then for each story: optionally run atdd to generate failing acceptance tests before development, run automate after the feature is built, and optionally run test-review to audit quality. The trace workflow refreshes the coverage matrix as tests accumulate.

At the release gate, trace Phase 2 evaluates everything and produces a PASS/CONCERNS/FAIL/WAIVED decision with evidence.

You don't have to use every workflow. Plenty of teams start with just automate and add the planning workflows as they see the value. TEA is designed to be adopted incrementally.

What Makes TEA's Tests Different

Three things separate TEA-generated tests from "just ask the AI to write tests":

Risk-based prioritization. Tests aren't generated uniformly. High-risk features get deep coverage. Low-risk features get a smoke test. This matches how experienced test architects actually think — you don't spend the same effort testing a payment flow and a color theme toggle.

Knowledge base patterns. TEA carries a knowledge base of 42 testing fragments covering fixture architecture, network-first patterns, step-file organization, and quality standards. Every generated test follows these patterns. The fixture architecture alone — pure function → fixture → composition — prevents the most common source of test rot: fixtures that are coupled to implementation details.

Network-first approach. Instead of using page.waitForTimeout(2000) or hoping the page loads fast enough, TEA's patterns intercept network calls before navigating. Tests wait for actual responses, not arbitrary delays. This is the single biggest factor in eliminating flakiness.

Enterprise and Brownfield Support

TEA handles more than greenfield projects.

For brownfield projects (existing codebase, existing tests), start with trace to baseline your current coverage. TEA maps what's tested and what's not, identifies regression hotspots, and focuses the test design on the areas where new work intersects with existing risk. You don't throw away your existing tests — you improve them incrementally.

For enterprise projects with compliance requirements, TEA's nfr-assess workflow captures security, performance, and reliability requirements early. The release gate produces audit-trail artifacts that map to SOC 2 and HIPAA evidence requirements.

Try It

The fastest way to see TEA in action:

npx bmad-method install  # Select TEA

Then in your AI coding tool: bmad-tea → framework → test-design → automate → npx playwright test.

Thirty minutes. Risk-based test plan plus passing tests. No test rot.

Full documentation: TEA Docs
GitHub: bmad-code-org/bmad-method-test-architecture-enterprise

Using TEA on a real project? I'd love to hear how the risk-based approach compares to your previous testing workflow — drop it in the comments.