That rule is what makes it workable to hand over a functional document and get back a test suite spanning API, UI, mobile, performance and security, without spending the next sprint discovering which parts of it were invented along the way.

The phase map

flowchart TD
    A["Functional spec<br/>(doc, images, exports)"] --> B["Phase 1: Analysis<br/>Output: test flows + open questions"]
    B -- "Blocking gap unanswered" --> B
    B -- "Blocking/high resolved" --> C["Phase 2: Contract gate + API tests<br/>Output: full API test suite"]
    C --> D["Phase 3: UI tests<br/>(only if a web UI exists)"]
    C --> E["Phase 4: Mobile tests<br/>(only if a native app exists)"]
    D --> F["Phase 5: Performance tests<br/>Output: load test scripts"]
    E --> F
    G["Phase 6: Security scan<br/>(runs anytime)"] -.-> C
    H["Phase 7: Page-speed audit<br/>(runs anytime)"] -.-> D

What happens where

Analysis. Takes the functional document, in whatever format it arrives, and produces test flows plus a structured question log. Questions are triaged by severity, and blocking or high-severity gaps have to be resolved, one round at a time, before anything downstream gets generated. Leave one blank and it’s marked pending, not assumed. The analysis simply runs again once the real answer exists.

Contract and API tests. Nothing gets built on top of an API contract until it clears a linting gate. Once it does, this phase generates realistic test data per entity and a full assertion suite: happy path, authentication, role-based access, validation, not-found handling, and checks that specifically try to make one user reach another user’s data.

UI and mobile, both conditional. These only run if the project actually has a web interface or a native mobile app. Each produces two things per screen: functional coverage and an accessibility pass, so accessibility isn’t a separate initiative bolted on afterward.

Performance. This is the one phase that refuses to guess at load numbers out of thin air. It reads two plain-language questions answered back in the analysis phase, who uses the system and what would hurt most if it broke, and derives concurrency targets and SLAs from that, instead of defaulting to an arbitrary number of virtual users.

Security and page-speed, both independent. Neither depends on the phases before it, and both can run at any point once there’s a live environment to point them at. One scans for real vulnerabilities against the running API; the other measures actual page performance and reports specifically what’s slow and why.

Why the branching matters more than the count

The interesting part isn’t that there are seven phases, it’s that most of them are conditional or independent. A backend-only service skips UI and mobile entirely. A project with no agreed SLAs still gets a performance suite, just one honestly labeled as a default instead of a false promise of precision. That shape, generate what applies, skip what doesn’t, gate what’s uncertain, is the same judgment I’d apply running this by hand. The pipeline just holds the line on it at a scale a manual process never could.

That question came from years spent as a QE Manager before I ever wore an AI-native hat. It’s the reason the agentic quality pipeline I designed and now run in daily production use wasn’t built as an AI project with some testing bolted on. It was built as a testing discipline that happens to be executed by AI.

What it does, at a high level

Given a functional specification, the pipeline autonomously generates a complete test suite, covering API, UI, mobile, performance and security, orchestrated across multiple AI coding agents working in concert rather than a single model doing everything. It doesn’t just produce tests that run; it produces tests wired directly into the same CI/CD safeguards a human-authored suite would go through, so nothing generated is exempt from the checks everything else has to clear.

The criteria it’s built on

None of that is trustworthy on its own. What makes it usable at scale, across 25+ teams, is a set of QE principles enforced on top of the generation, not left to the model’s judgment:

• Traceability first. Every generated test maps back to an explicit acceptance criteria, not to a guess at what “looks testable.” If a test can’t be traced to a requirement, it doesn’t ship.
• Risk-based coverage. Effort is weighted toward the areas with the highest business impact and the highest rate of change, the same prioritization I’d apply manually, not spread evenly across the codebase because evenly is easier to automate.
• Test pyramid discipline. Unit and API-level assertions form the backbone; UI and end-to-end tests are reserved for what genuinely requires a browser or a device, not generated by default because they’re the easiest thing to visualize.
• Maintainability as an output, not an afterthought. Generated tests follow the same structural patterns enforced in our manually authored suites, Page Object Model and Screenplay-style separation, SOLID structuring, so a generated test and a human-written one are indistinguishable six months later when someone has to maintain it.
• Validated fault detection, not just green checkmarks. A test that passes isn’t automatically a good test. Generated suites are held to the same mutation-testing standard I’d apply to any team’s coverage: if a test can’t catch a deliberately introduced defect, it doesn’t count as coverage.
• A human still holds the gate. Every generated case is reviewable and overridable by a QE before it reaches CI. I treat the agent as a fast, tireless junior tester, not an unsupervised authority, which is exactly how I’d onboard a junior engineer onto a team I was managing.

Why both hats had to be on the same head

An AI-native Delivery Manager without QE depth ships something that produces green checkmarks and calls it coverage. A QE Manager without delivery fluency never lets an agent near production test suites at this scale, the operational trust just isn’t there. This pipeline exists because both of those perspectives had to make the same call at once: is this a good test, and does it belong in how we deliver.

That discipline is also why the results attached to it are what they are. The AI doesn’t produce numbers. The criteria does. The AI just makes it possible to apply them at a scale no manual QE process could match.