Can AI really write your test cases?

There is growing confidence in artificial intelligence and its potential to improve software delivery and testing. One of the strongest claims is that AI can read requirements, scan code, and produce test cases at a speed no test team could match manually. For delivery leaders working under time and cost pressure, that is understandably attractive. 

But faster production of test artefacts is not the same thing as confidence in product quality. Test cases are not there simply to show that testing has been done. They exist to reduce the chance that poor-quality, unsafe, or confusing behaviour reaches real users. If organisations remove human-centred testing and rely too heavily on machine-generated coverage, they risk losing the judgement that notices gaps, assumptions, and user impacts that are rarely visible in requirements or code alone.

Speed and volume vs. real confidence

Given source material such as requirements, acceptance criteria, or code, AI can draft large volumes of test cases quickly. Used well, that speed can remove repetitive effort and help teams build a first pass of coverage more quickly. 

But volume is not the same thing as confidence. A larger set of generated tests can easily create the impression that quality has improved, when in reality the testing has simply become more efficient at documenting the obvious.

Quality failures often sit in ambiguous requirements, awkward edge conditions, unintended user paths, brittle integrations, and business rules that work as coded but still lead to poor outcomes for the user. More AI-generated tests do not automatically mean deeper understanding.

My approach: Bringing the human perspective in early

Because AI output is only a starting point, the human element must be integrated from day one. In my work at Assurity, I involve test analysts early – not only when a feature is ready to be checked, but when requirements, assumptions, and delivery risks are still being shaped.

If AI is being used to generate test cases from requirements, stories, or code, I treat that output as a draft rather than a finished asset. For me, the focus is always on understanding where business risk sits, where customer impact is the highest, and where human review needs to be strongest.

That review step matters because accountability still needs to sit with people. I make that explicit by requiring test scope, identified risks, and mitigations to be visible and understood before release decisions are made. Where AI suggests a broad set of cases, I expect a tester to decide which ones are useful, which ones repeat the same idea, and which ones do not reflect how the product will behave in the real world. 

When an AI-generated test passes, I still want to know whether the result is meaningful. I do not treat AI output as enough on its own; I want human validation. That takes more effort upfront, but it is a far more responsible way to protect quality than assuming the tooling has already done the thinking for us.

Human-centred Intelligence working in collaboration with AI

The integration of AI into software QA presents a compelling strategic opportunity, yet the true value is unlocked not through replacement, but through a deliberate human-centred collaboration. 

While AI undeniably excels in generating high-volume test artefacts quickly, its output is fundamentally a reflection of the source material – requirements, code, and known patterns. This speed, while attractive for delivery leaders, must be viewed as an augmentative force, not a surrogate for critical thinking.

AI’s capacity to draft extensive coverage and build out permutations removes significant repetitive effort, allowing QA teams to achieve a faster initial pass on test coverage. This efficiency shift frees up the most valuable QA resource: the experienced test professional, enabling them to focus on true risk.

The QA professional provides the essential judgement that elevates mere volume to genuine confidence. Quality failures often reside in the grey areas – ambiguous requirements, awkward edge conditions, and unintended user journeys that are rarely visible in requirements or code alone. This is where human-centred testing provides its unique benefit to the AI-driven process:

Contextual validation: Human QA professionals apply lived experience, practical context, and business knowledge to analyse AI-generated drafts, deciding which cases are truly useful and which ones simply repeat obvious concepts.

Risk prioritisation: The human element ensures that testing remains focused on customer impact, business risk, and critical workflows. It is the person who must decide what ‘quality’ looks like and where accountability sits.

Exploratory leadership: Manual and exploratory testing remain absolutely vital, particularly in areas where potential harm can occur. AI can suggest scenarios, but the human retains the curiosity and judgement to explore what formal logic may miss.

Whilst AI benefits QA by providing speed and scalability, while QA benefits the AI output by injecting necessary wisdom, relevance, and accountability. Organisations should leverage AI as a deliberate tooling choice within a broader, human-led quality strategy. This balance is key to protecting product quality in a responsible way.

Are you ready to strike the right balance between AI speed and human confidence in your testing?

Connect with me on LinkedIn or reach out to the Assurity team today to discuss a smarter, safer quality strategy for your next release.