Should AI Write Your Test Cases?

"Just let AI write the test cases."

If you work in testing, you've probably heard some version of that line this year. It sounds like the obvious next step. AI is getting better every month, release cycles keep getting shorter, and nobody has enough testers.

Here's the honest answer: AI can genuinely help. But it also gets things wrong, and when it's building the tests that decide whether your software ships, "usually right" isn't good enough.

The real question isn't whether to use AI. It's whether you can see what it's doing and check it against something ‘concrete’.

Four Generations of Test Case Design 

Test case design isn't new, and AI isn't the first thing that promised to fix it. The approach has already been through four big shifts:

1. Manual test cases. A tester reads the requirement and writes the cases by hand.
2. Mathematical techniques. Methods like cause and effect modelling and orthogonal arrays brought more rigour to which combinations got tested.
3. Controlled natural language. Formats like Gherkin gave requirements and tests a shared, structured way of being written.
4. Model based testing. Instead of writing tests directly, teams model the logic and generate tests from it. This started with tools like Agile Designer and has evolved into what we now build in Quality Modeller.

Each generation was a genuine step forward. And yet the same core problems made it through every one of them.

The Problems that Never Went Away 

Ask any test lead what's wrong with their test suite and you'll hear some version of these:

• Test cases never die. They pile up release after release. They rarely get retired when the logic they covered changes or disappears.
• Many of Them Are the Same. Manually written cases are often duplicates of each other, which adds effort without adding coverage.
• Nobody can say what's covered. Most teams have no reliable way to measure what percentage of their application logic is actually tested.
• One small change touches everything. A minor tweak to a requirement can mean reconsidering every related test case, by hand.
• The Ceiling is Human. A manual tester can realistically create around six or seven test cases a day. Release cycles didn't slow down to match.
• Suites can't flex. You can't easily expand or shrink the test set as the requirement or the code changes.

None of these are about the tester. They're about the way test cases get created and how they are maintained: written once, by hand, and then left to age.

Why AI alone doesn't fix it 

So, it makes sense that teams are turning to AI. If a tester can write six or seven cases a day, AI that writes hundreds an hour looks like the answer.

The catch is that speed only helps if the tests are right. AI is getting more capable all the time, and it can be very helpful. But it isn’t always right. Hand it a vague requirement and it will happily fill the gaps with assumptions, and you won't always know which parts it guessed.

That creates a new version of an old problem. Instead of a pile of handwritten tests nobody fully trusts, you get a much bigger pile of AI generated tests nobody can fully check.

For AI to be trusted in testing, two things need to be true:

• It must be observable. You need to see what it's doing, not just what it produced.
• Its output must be checked against something concrete. Not a document open to interpretation, but a clear definition of what the system should do.

If you can't observe the AI, you can't trust the tests.

The fix: validate the model first, then let AI loose

That ‘concrete thing’ is a visual model of the requirement.

People process visuals far more naturally than walls of text. Lay a process out as a model and the logic, the decision points and the missing branches become obvious in a way they never are in a written spec. That makes it something a team can understand and actually agree on.

So, the order matters:

1. Build the model. Map the process and the business rules visually.
2. Agree it together. Everyone involved refines it and layers in the business constraints until there's consensus that the model matches the requirement.
3. Then generate the tests. Only once the model is validated does anything get generated from it.

This is where AI earns its keep. With a validated model underneath it, AI can:

• Create covered tests straight from the requirements

• Match test data to those requirements
• Run quality reviews that flag gaps and areas of low coverage

AI sits on top of a validated model, not in place of one. The humans decide what's right. The AI does the heavy lifting from there.

And because the tests come from the model, the old problems start to shrink. When a requirement changes, you change the model once and regenerate, rather than combing through every test by hand. Coverage becomes something you can measure, because you can see exactly which paths are tested. The goal shifts from more tests to the right ones: the minimum number of tests for the maximum coverage.

One model, every stakeholder 

There's a bigger benefit hiding in here. In most organisations, every function works from its own version of the truth. Business analysts have documents. Developers have code. Quality engineers have test scripts and automation. DBAs have schemas. Each one describes the same system slightly differently, and the gaps between them are where defects live.

A shared visual model gives everyone one source of truth to work from. Teams can use it to:

• Visually define complex processes and reduce misalignment
• Find gaps and improve understanding before anything is built
• Align every stakeholder around the same picture
• Create the assets the team needs early: tests, data and automation

The models also become something AI can learn from. Captured business logic stops living in one person's head and becomes a foundation that helps reduce knowledge silos across the organisation.

What it looks like in practice 

One global accounting firm used this approach to rethink how it turned requirements into test cases. Before, converting a single requirement into test cases took roughly 7 hours. With an AI accelerated, model-based workflow, it took around 45 minutes.

The important part is what didn't change: people stayed responsible for confirming the model was correct. The AI made the work faster. The humans made sure it was right.

As Harry Burn, Head of Solution Engineering at Curiosity Software, puts it:

"AI can be very helpful, but you can't rely on it alone. To trust what AI produces, it has to be observable. That's what a visual model gives you: a way for humans to quickly confirm the model and its constraints actually match the requirements, before that model is used to generate a single test case."

If you want to see what happens when requirements change under this approach, Huw Price walks through a full example in The Requirements Change Problem, where one model update flagged 64 affected paths and regenerated 279 test cases in minutes.

So, should AI write your test cases? 

Yes, with a model it can be checked against and a human who signs that model off.

AI on its own just produces more tests, faster, with the same blind spots. AI on top of a validated visual model gives you fewer, better tests you can actually measure, maintain and trust.

Quality Modeller is built around exactly that: visual, model-based test design with observable AI assistance, available now as part of the Curiosity platform.

So, here's a question worth asking your team this week: what percentage of your application's logic do your test cases actually cover? If the honest answer is "we don't know", that's the place to start.

AI you can check. Tests you can trust. Not sure what your tests really cover? Book a meeting with a Curiosity expert and find out.