Why Your BMAD Workflow Needs TEA And What Happens When It Does Not

The case for adding a dedicated test architecture layer to your AI-assisted delivery pipeline

The test quality problem BMAD alone cannot solve

BMAD is a planning and implementation methodology. It tells you how to structure requirements, break down architecture, create stories, and guide an AI agent through implementation. It does all of this well.

What BMAD does not do is tell you whether what was built is adequately tested, whether the tests themselves are trustworthy, or whether the test coverage is sufficient to make a confident release gate decision. BMAD has a built-in QA agent. That agent can write tests. But writing tests and building a test architecture are different things and the distinction matters more when the tests are being generated by AI.

TEA was built to solve AI-generated tests that rot in review. That single sentence is the most important thing to understand about why TEA exists alongside BMAD. The problem it solves is not "we have no tests." It is "we have tests that look productive but provide false confidence." If your AI tests look productive but rot in review, you do not have a test suite, you have a slop factory.

This article explains precisely what that means, what TEA does about it, and when an organisation should seriously consider adding it to their BMAD workflow.

What AI-generated tests look like without a test architecture

When bmad-dev-story implements a story and the built-in QA agent generates tests, the output is plausible. The tests run. They pass. They are committed. They show up in coverage reports.

Three sprints later, a refactor renames a CSS class. Fourteen tests failed simultaneously not because the feature broke, but because every test was asserting against page.locator('.property-card-submit') instead of page.getByRole('button', { name: 'Submit' }). The engineer fixes the selectors. Two sprints after that, a different refactor changes an API response shape. Eight tests failed not because the feature broke, but because the tests were checking the DOM without asserting the API response that populated it.

This is test rot. The tests were generated, they passed at the time, and they degraded silently. Nobody noticed because the coverage percentage stayed high. The number that looked like quality was measuring quantity.

Without a test architecture, AI-generated tests have four consistent failure modes:

Brittle selectors. AI agents default to the most obvious locator, typically a CSS class or XPath. These are implementation details, not user-visible contracts. They break when the implementation changes even when the feature behaviour has not changed.

Missing API assertions. AI agents test what they can see: the DOM. For features that load data via API, a test that only checks the DOM can pass even when the API returns an error and the UI is showing cached stale data. The test is measuring the wrong thing.

Positive path only. By default, AI agents follow the happy path. When tests fail to evaluate error states, validation issues, empty states, or permission denials, they do not provide coverage; rather, they merely document the success case.

Non-deterministic flows. AI agents reach for waitForTimeout when a condition needs to wait. Hard waits are timing-based and environment-dependent. Tests that pass on a developer's machine fail in CI. Tests that pass in CI fail under load. The test suite becomes unreliable precisely when reliability matters most.

A test architecture is the set of standards, patterns, and review mechanisms that prevents these failure modes from accumulating. Without one, every sprint adds to the debt. With one, the debt is caught at the story level before it compounds.

What TEA actually provides

TEA (Test Engineering Architect) is a BMAD module for testing strategy and automation. It provides nine workflows covering learning, setup, design, automation, review, and release gates.

Those nine workflows span the entire delivery lifecycle, not just the implementation phase:

Before implementation begins: test-design analyses the PRD, architecture, and ADRs to produce a risk-based test plan. Risk scoring uses probability × impact to prioritise P0–P3 scenarios. The team knows before a single line of code is written which scenarios carry the most risk and what evidence will be required at the release gate. This is qualitatively different from discovering test gaps at code review.

atdd generates failing test scaffolds from acceptance criteria before implementation begins. The scaffolds define what passing looks like. The AI agent implements them. This is test-driven development at the story level. The acceptance criteria drive the implementation, not the other way around.

After implementation: automate expands coverage with Playwright specs and Page Object Models generated after implementation. Unlike atdd scaffolds which are pre-implementation, automate tests pass immediately because the feature exists. The test-review workflow audits test quality with objective scoring 0 -100 across Determinism, Isolation, Maintainability, and Performance.

At the release gate: trace provides two-phase traceability: Phase 1 maps tests to requirements, Phase 2 makes the gate decision. The output is a Go/No Go with evidence, not a subjective judgment. nfr-assess audits non-functional requirement evidence (performance, security, reliability) when that evidence is required for release.

The five reasons to add TEA to a BMAD workflow

Reason 1: Risk-based test design before implementation

BMAD's planning phase produces a PRD and architecture. But without TEA, test strategy is implicit; an afterthought assembled during code review rather than an explicit plan made before implementation begins.

TEA's test-design workflow produces a risk assessment using probability × impact scoring, NFR thresholds and evidence plan, and an integration risk analysis. The team knows which acceptance criteria are P0 (must pass before any release), which are P3 (nice to have), and which non-functional requirements need evidence at the gate. This changes how stories are estimated, how implementation is prioritised, and how confident the team is when it reaches the gate.

Without this, teams discover test gaps at Gate 1 or Gate 3. With this, the gaps are identified and planned for in Phase 3 before anyone writes a line of code.

Reason 2: ATDD makes the acceptance criteria executable before implementation

bmad-testarch-atdd translates acceptance criteria into failing test scaffolds. These scaffolds do three things simultaneously.

They make the acceptance criteria precise. Vague AC like "the user should be able to search for properties" becomes a concrete failing test that specifies what inputs produce what outputs under what conditions. Ambiguity that would have surfaced as a mid-sprint dispute surfaces instead during Spec Review when the scaffold is reviewed by the team.

They give the AI implementation agent a verification mechanism. bmad-dev-story implements against the story file. When the story file includes failing ATDD scaffolds, the agent has a passing criterion it can verify against. Implementation quality improves because the agent can check its own work.

They define what done means objectively. A story is not done when the engineer says it looks good. It is done when the ATDD scaffolds pass, the automate coverage is adequate, the test-review score meets the quality threshold, and the trace confirms the acceptance criteria are mapped to tests. None of this is possible without TEA.

Reason 3: Objective test quality scoring catches what code review misses

Code review is a human process. Reviewers catch logic errors, architecture violations, and obvious quality issues. What code review consistently misses is test quality, specifically the four failure modes described earlier: brittle selectors, missing API assertions, positive-path-only coverage, and non-deterministic flows.

TEA's test-review workflow audits tests against its knowledge base of best practices and produces a 0–100 score across Determinism (30%), Isolation (30%), Maintainability (25%), and Performance (15%). The score is objective and consistent. It does not depend on the reviewer's testing expertise or the amount of time they had to review the test file.

For teams generating tests with AI agents, objective test quality scoring is not optional. AI agents generate tests that look correct but contain subtle quality issues that compound over time. A test file that scores 58/100 today will score lower in three sprints after three refactors have broken its brittle selectors. Catching the quality issues at score 58 is significantly cheaper than catching them when fourteen tests fail simultaneously in CI.

Reason 4: Requirements traceability enables confident release gate decisions

Without TEA, the release gate decision is a judgment call: does the team feel confident enough to release? With TEA, it is an evidence-based decision: do the tests cover the acceptance criteria, do the non-functional thresholds pass, and does the traceability matrix confirm coverage?

TEA's trace workflow provides Phase 1 coverage mapping and Phase 2 gate decision (PASS / CONCERNS / FAIL / WAIVED). The gate decision is backed by a traceability matrix that links every test to the requirement it covers. Gaps are explicit. The team does not have to guess whether the feature is adequately tested, they can see which requirements have test coverage and which do not.

For organisations with compliance requirements (SOC 2, HIPAA, financial regulations, audit trails), TEA's enterprise track includes NFR evidence auditing and artifact archiving specifically for compliance and regulatory contexts. This is not something the BMAD built-in QA agent can provide.

Reason 5: Brownfield regression risk is managed systematically

The regression risk associated with every single modification is substantial and frequently obscured for enterprises operating within a brownfield codebase characterized by legacy products, partial test coverage, and a buildup of technical debt.

For brownfield projects, TEA's recommended approach starts with a baseline trace in Phase 2 to map existing test coverage before planning begins. Epic-level test-design then focuses specifically on regression hotspots and brownfield integration risks.

Without this baseline, teams adding AI-assisted implementation to a brownfield codebase are flying blind on regression risk. They know the new story passes its own tests. They do not know whether the changes made to shared modules, legacy services, or existing API contracts have broken anything that was working before.

TEA's coverage delta tracking (baseline before the story, delta after) makes regression risk visible at the story level. The team knows not just "did our new tests pass" but "what happened to the coverage of the code we touched."

When TEA is not necessary

The official TEA documentation is explicit about this: BMad does not mandate TEA. Quick Flow projects typically do not require TEA.

For small, isolated changes, a one-file bug fix with existing test coverage, a trivial Quick Flow item, the overhead of test-design, ATDD scaffolds, and test-review scoring is disproportionate to the risk. The existing tests adequately cover the change. The fix is small enough that a careful code review catches any test quality issues.

TEA adds the most value when:

• The work is non-trivial - multi-file, multi-component, or architecturally significant
• Regression risk is real - existing code is being changed, not just new code being added
• The team is generating tests with AI agents - not hand-writing tests
• Release gates require evidence - compliance, NFR thresholds, or stakeholder sign-off
• The codebase is brownfield - existing coverage is partial, inconsistent, or unknown

For teams in this position which describes most enterprise product engineering teams, TEA is not an optional enhancement. It is the quality layer that makes AI-assisted delivery reliable enough to ship with confidence.

The decision is not all-or-nothing

There are five valid ways to use TEA (or skip it). Pick one intentionally.

Teams do not have to adopt all nine TEA workflows immediately. The engagement models range from TEA Lite - just use automate to test existing features, thirty minutes to get started to fully integrated enterprise with ATDD, NFR evidence auditing, and compliance artifact archiving.

A pragmatic adoption path for a team currently using BMAD without TEA:

Sprint 1: Add bmad-testarch-test-review to the existing workflow. Run it on every new Playwright spec file before Gate 1. Nothing else changes. The team gets quality scores immediately. They see where the issues are.

Sprint 2–3: Add bmad-testarch-atdd to Spec Readiness. Generate failing scaffolds before implementation begins. Review them with the team in Planning Pt 2. The acceptance criteria become precise. Implementation quality improves.

Sprint 4+: Add bmad-testarch-trace to the release gate. The team now has evidence-based gate decisions rather than judgment calls.

Each step is independently valuable. Each step makes the next step easier. The test architecture builds incrementally, sprint by sprint, in the same way that a delivery workflow builds incrementally.

The alternative, shipping AI-generated tests without a quality layer is not a stable equilibrium. The test debt compounds. The selectors get more brittle. The false confidence grows. The day when fourteen tests fail simultaneously in CI is not a risk. It is a schedule.

This article draws on hands-on experience customising BMAD and TEA for production use.