Beyond the fear: Practical approaches for AI quality and accuracy

Testing AI applications requires the same rigour as any other software; they don’t need to be scary! Many organisations are still finding their footing and taking a very cautious approach. Whilst being cautious is good, AI testing is not an intimidating new frontier; it is the natural evolution of professional quality assurance. While AI introduces unique variables – such as unpredictable response patterns and the need to measure human-centric efficiency – the core objectives remain unchanged.

We still start with a hypothesis, define what success looks like, and measure the evidence. By applying structured, scalable testing frameworks like Assurity’s AutomationFlex, we can move beyond ‘pass or fail’ metrics to effectively validate the accuracy, reliability, and business value of AI-driven tools throughout their entire lifecycle. AI is simply the next puzzle for us to solve, and as testers, that is exactly what we are built to do. However, based on what I have seen, AI is not something to be afraid of. It is simply another type of application that needs quality assurance.

We still start with a hypothesis

As with any testing activity, we begin with a hypothesis: This software does these things, and we need to prove it.

That part has not changed. We still read the requirements. We still identify what needs to be proven. We still consider risk, complexity, users, data, and expected outcomes. This is still a key to our testing analysis and design process.

What may be different is the language used in the requirements. For example, we may now see statements such as:

• “We expect to see an efficiency improvement.”
• “The AI tool must provide accurate responses.”
• “The solution should improve the user experience.”
• “The tool should reduce manual effort.”

In my view, this is not a fundamental change to testing. These are still claims that need to be tested. The challenge is defining how we prove them.

Testing efficiency gains

Let’s unpack the statement: “We expect to see an efficiency improvement.”

To test this properly, we first need to understand the current process. How long does it take today to get from point A to point B? What are the current steps? Where are the delays, handovers, or manual tasks? Without these metrics and understanding captured before changes are made, we cannot prove whether the AI tool has made anything better.

Next, we need to understand where the AI tool fits into the process:

• What task is the AI tool performing?
• Which part of the process is being changed?
• Who is using the AI tool?
• What level of skill or experience do those users have?
• How much variation exists between users?

Only once we understand the current process and the role of the AI tool can we design a meaningful test.

Metrics also help us track how future changes impact the system, allow tracking of Quality indicators and much more.

One or two test runs are not enough

If we only run the test once or twice, the results will not tell us much. We need to collect as many data points as possible. In the first instance, this testing is likely to be human-centric. We are not only testing the AI tool itself; we are also testing how effectively people can use it within a real process.

That matters immensely. If the users are highly experienced with AI, the results may look very different from those achieved by everyday users who are less familiar with the tool. For this reason, it is important to ensure there is fair representation from the intended end-user group. In other words: do not only test with a group of AI evangelists.

Scaling the testing effort

Once the human-centred testing has been established, the next step is to scale the AI component of the process. This is where automation becomes important.

To scale this without overwhelming your team, frameworks like Assurity’s AutomationFlex allow you to execute a massive volume of test scenarios and generate a much larger set of data points. This gives us a solid basis for comparison and helps reduce reliance on a small sample of manual observations. The more data we collect, the better our ability to assess whether the AI tool is genuinely improving the process.

Testing accurate responses

Now let’s consider another common requirement: “The AI tool must provide accurate responses.”

This introduces a different testing challenge. AI will not always provide the same response every time, i.e. it is non-deterministic. Similar prompts can produce different answers, and there is a high degree of variability in how responses are generated. So, what can we realistically do?

One practical approach is to give the AI tool an exam. We define a controlled set of prompts that test the AI tool’s ability to provide the required information. These prompts should also test the guardrails, boundaries, and expected behaviours of the tool. Then we define what makes a good answer on a scale to allow us to judge the grey area. That means collaborating with our key stakeholders and end users to agree upfront on the assessment criteria. For example:

• Is the response factually correct?
• Is it relevant to the prompt?
• Is it complete enough for the user’s needs?
• Is it clear and understandable?
• Does it stay within the expected boundaries?
• Does it avoid unsupported or misleading claims?

Once we know what a good answer looks like, we can measure the AI tool’s responses against that standard. Testing of accuracy is not a one-off test; we need enough data to compare results, identify patterns, and understand the level of variation.

The power of AI as a judge

To evaluate these varied responses efficiently, there is a massive opportunity to use an “AI as a judge” technique. This involves using a controlled Large Language Model (LLM) to evaluate the outputs of your primary AI tool against a strict, predefined rubric.

This accelerates the analysis process, allowing you to assess large volumes of responses against your defined criteria in seconds, while still allowing human review and oversight where needed. The important point is that the evaluation approach needs to be structured. We should not rely on gut feel alone.

Always keep an eye on our friendly AI friends, though, as they have been known to figure out that they are being tested. Having a human in the loop is a very necessary precaution.

What is the right size for testing AI?

Another challenge is deciding the right size of the testing effort. AI has changed where some of the effort sits when developing a solution. AI tools can often be fast and easy to set up, meaning the real effort comes in the quality assurance space, not only before the tool is released, but also after it is live.

Before we allow an AI tool to “leave the nest”, aka go into production, we need to understand how much testing is enough. That decision should come back to the criticality of the system.

We need to consider the usual testing factors:

• Who is using the tool?
• What are they using it for?
• Where will it be used?
• When will it be used?
• How much reliance will be placed on the output?
• What happens if the tool gets something wrong?

These questions help us understand complexity, criticality, and risk. The higher these factors are, the more focus we need to place on quality assurance. As always, collaboration is key to defining the scope; remember to bring that testing mindset and think about what is important to the business!

Quality does not stop at release

Once an AI tool has been released into the wild, testing does not stop. AI models change. Source data changes. Business processes change. User behaviour changes. What was effective yesterday may not remain effective tomorrow. This means that regression testing is even more important than ever!

Just like in a normal software development lifecycle, we need ongoing monitoring and assurance. We need to remain vigilant and continue checking that the AI tool is still effective, accurate, and appropriate for its intended use. AI regression testing is no different. Again, this is an opportunity for AutomationFlex and ExMonitoring or similar automation frameworks to support ongoing testing and monitoring.

The game has not changed

The key point is this: the game has not really changed. Our objectives are still the same. We are here to ensure quality.

As testers, test engineers, and test managers, our careers have always required us to adapt to an ever-changing landscape. We have adapted from waterfall to agile. We have adapted to automation. We have adapted to DevOps. AI is simply another puzzle for us to solve.

Testing is a science. Tests are experiments. We design them to prove or disprove something. AI may introduce new variables, but the mindset remains familiar:

• Define what good looks like.
• Design a way to test it.
• Gather evidence.
• Analyse the results.
• Make an informed decision.

Testing AI is not scary. It is just quality assurance evolving again. And as testers, that is exactly the kind of challenge we are built for.

Are you preparing to roll out a new AI tool but struggling to define how to measure its quality, accuracy, and efficiency? Contact Assurity’s quality engineering team today to baseline your current processes and build a robust, scalable testing strategy for your next AI initiative.