In the first post of this series, Robby Putzeys looked at how AI is changing quality engineering, not just what it can do, but how to use it in a structured, consistent way. From automating routine tasks to improving test design, the key is to make AI work predictably and at scale.
In this post, I’ll focus on a question that comes up again and again with QA leaders. How can AI-generated test scenarios be trusted to deliver reliable, repeatable results across releases and regulated environments?
AI-written test cases are already widely accepted. The question isn’t whether they work in isolation, but whether they can be trusted as part of an engineered QA system. For QA leadership, inconsistency is not a minor inefficiency – it directly increases risk.
Test design has always been vulnerable to variation. Two experienced testers reviewing the same requirement will often produce different scenarios, focus on different edge cases, and apply different assumptions.
Generative AI magnifies that risk if it’s used naively.
Ask a large language model to generate test cases twice and you’ll likely get:
That kind of non-determinism makes AI output difficult to:
So we deliberately framed the problem differently.
The goal isn’t to make AI creative.
The goal is to engineer AI-driven test design so it behaves predictably.
You can’t remove the probabilistic nature of generative models, but you can design the surrounding system so outcomes are constrained and repeatable. We treat AI-driven test design as an engineering problem, not a tooling choice.
That means controlling the inputs, constraining the way scenarios are expanded, by validating outputs before they reach humans and making sure there is a clear audit trail back to source artefacts. The AI is never working in isolation. It operates within a defined pipeline that is designed to produce consistent results, even as systems and teams scale
We deliberately avoid framing this as ‘AI generates test cases’. Instead, test design is broken into explicit stages that mirror how experienced QA teams already think – but executed with far more consistency.
Everything starts with direct integration into existing sources of truth. Requirements, acceptance criteria, design documentation, API specifications and historical defect data are ingested automatically rather than being manually summarised or reinterpreted. This removes one of the biggest sources of variability before AI is even involved.
Those inputs are then normalised into a structured internal model. Business rules are extracted and de-duplicated, data entities and constraints are identified and known risk areas are tagged using historical defect patterns. This step is critical. Without it, AI output quality simply reflects the inconsistency of upstream documentation.
Only once that foundation is in place is AI used to expand test coverage. Even then, it is not asked to decide what to test. Instead, it’s constrained to expand scenarios across predefined dimensions such as functional behaviour, negative and boundary conditions, integration paths and relevant non-functional concerns. This ensures breadth and depth without relying on subjective judgement from the model.
Before anything reaches a tester, generated scenarios are automatically validated. Coverage is checked against the original inputs, traceability links are enforced, and contradictions or gaps are flagged. Scenarios that fail these checks simply don’t progress further.
Consistency does not come from better prompts alone. It comes from treating AI behaviour as something that must be constrained, validated, and observable.
We apply guardrails at multiple levels. The way the AI is instructed is tightly structured, with fixed expectations around output shape and depth. Generated scenarios must conform to a defined schema rather than free-form text, which makes them reviewable, comparable and automatable. Completeness rules ensure that minimum coverage expectations are met for each feature, interface, or risk category.
The result is that AI is not free to ‘skip’ scenarios or reinterpret scope. It operates within clearly defined boundaries, producing outputs that behave more like the work of a disciplined test designer than an open-ended assistant.
Human oversight remains essential, but its role changes. Instead of manually checking individual test cases, test leads act as governance controls over the system itself.
Reviews focus on the completeness and relevance of scenario sets, rather than line-by-line edits. When issues are found, the response is not to fix the output manually, but to adjust constraints, validation rules, or input modelling so the same issue can’t happen again. Over time, organisational standards and risk appetite are effectively encoded into the system.
This approach allows teams to scale test design without scaling review effort or introducing new bottlenecks. AI does the repetitive, exhaustive work. Humans keep the accountability and judgement.
The most visible benefit is speed, but that’s not the most important one. What changes fundamentally is predictability.
Test design becomes less dependent on individual experience and availability. Coverage is broader and more balanced by default. Traceability is built in rather than reconstructed later for audits. Release confidence improves not because more tests exist, but because coverage is demonstrably consistent from one release to the next.
For QA leaders under pressure to move faster without increasing risk, that predictability matters far more than raw automation metrics.
The system does improve with use, but in a controlled way. As new defects are discovered and new requirements are introduced, risk tagging and coverage expectations evolve.
Domain-specific behaviour becomes more refined, but always within the same constraints and validation rules.
AI in test design is not about replacing experience. It’s about capturing it, systematising it and applying it consistently across teams and releases.
AI-driven test design introduces new risks if it’s treated as a shortcut or a black box. Used properly – with clear architecture, guardrails and governance – it becomes a force multiplier for QA teams operating at scale.
In the next blog in this series, we’ll apply the same principles to AI-powered self-healing automation, where constraint and validation are just as important as intelligence.
If you’d like to discuss how this approach could fit into your existing QA landscape, we’re always happy to share what we’ve learned, including the lessons from approaches that didn’t scale.
Providing solutions in a unified, structured approach across all critical domains to enable end-to-end quality – Because we’re the only ones who can.
