AI has made it very easy to generate test cases.

Maybe a little too easy.

Give an LLM a requirement and it can give you 50, 100 or 200 test scenarios in seconds. But that leaves the harder questions unanswered: Which of those tests actually matter? Which risks are you trying to cover? Which tests deserve automation? And which ones are going to become maintenance work six months from now?

That is where the QA Risk Agent from TestResults starts.

Instead of beginning with test generation, it starts with the specification. It analyses what the system is supposed to do, identifies potential risks, helps you prioritise them and turns the important ones into logical test plans. Those tests can then move into exploration and automation inside TestResults.

The idea is simple:

Specification → risk → test → automation → risk coverage

So instead of measuring how much testing you are doing, you can start answering a more useful question: how much of your actual business risk are you covering?

Start with what could go wrong

Imagine a very simple specification for a text editor. It says that users should be able to save files, read files from their hard drive and undo an operation.

You could immediately turn that into three tests: save a file, open a file, undo a change.

The QA Risk Agent goes further. It analyses the specification and looks for the risks behind those requirements. What if Undo restores the wrong previous state? What if an operation causes corruption or a crash? Could supposedly deleted sensitive content be restored? What happens when there are concurrent writers?

Those are not automatically your new test cases. They are potential risks for the tester to review.

That distinction is important. The Agent isn't there to produce a huge list and tell you the job is done. A tester can remove an irrelevant risk, change its assessment or investigate it further. The aim is to give QA a much better starting point for deciding what deserves attention.

And once those risks exist, they can be prioritised.

Not every test deserves the same effort

A useful test strategy cannot treat every possible failure equally.

An incorrectly aligned icon and an incorrectly calculated bank transfer are both defects. They clearly do not carry the same business risk.

The QA Risk Agent assesses risks using frequency and damage. How often is this functionality used, and what happens if it fails?

That creates a risk map that teams can use to decide where their testing effort is best spent.

This becomes particularly useful for automation because every automated test creates maintenance. It does not matter whether that test was written by an engineer, generated by AI or created with a low-code tool. If the product changes, the test may need to change too.

So instead of asking how much of the application you can automate, the QA Risk Agent helps you ask which automation gives you the most valuable risk coverage.

We've seen a strong Pareto-like pattern here: when tests are prioritised correctly, roughly 20 to 30 percent can account for a disproportionately large amount of the overall business-risk coverage.

That is a very different target from “100% automation.”

****

The TestResults dashboard shows the current Overall Risk Score alongside Unrisking Speed, so teams can see both their risk position and how quickly new risks are being mitigated.

The dashboard reflects that idea. The Overall Risk Score, graded from A to F, shows the current risk position based on identified and mitigated risks. Unrisking Speed adds another dimension: how quickly can the team deal with new risk as the product changes?

Because having good coverage today is only half the problem. If the next release introduces 30 new risks and your testing process takes three months to catch up, yesterday's green dashboard does not tell you very much.

From risk to an actual test plan

Finding a risk is useful. Eventually, somebody still has to test it.

For a selected risk, the QA Risk Agent can create a logical test plan containing preconditions, test steps, assumptions and open questions.

Go back to our Undo example. The Agent might determine that the application needs to be running, a writable directory needs to be available and an editable file needs to exist. It can then propose a sequence for making edits, triggering Undo and checking whether the correct state is restored.

But one of the more interesting parts is what happens when the specification doesn't contain enough information.

Should the Undo history survive after saving? Is it stored only in memory? What happens if two instances have the same file open? Does Undo apply to the document or the entire application session?

If the answer cannot be established from the available information, that becomes visible as an assumption or open question instead of quietly becoming part of the test.

That means the Agent can be useful before anyone starts executing tests. Those questions can go back into refinement while there is still time to clarify the requirement.

****

Risks are organised around the relevant functionality, while the QA Risk Agent builds a logical test plan from the available specification and supporting evidence.

You can see that workflow in the Risk Management view. In this example, the Agent has identified separate risks around undo availability, undo mechanics, concurrency and file persistence. On the right, the logical test planner works through context setup, evidence retrieval, structured generation and validation.

So this isn't simply “give ChatGPT a user story and ask for test cases.” The Agent works from the context available for the actual system and keeps the resulting test connected to the risk that created it.

Logical tests first, physical tests second

That connection becomes particularly important when you move into automation.

Consider a business rule that says:

Customers must be at least 18 years old.

A logical test could be:

Verify that a customer aged 18 or older is eligible.

But your application probably doesn't contain a field labelled “Age”. It contains a date-of-birth field. The physical test needs to calculate an appropriate date, enter it into the actual interface, trigger the eligibility process and verify the result.

TestResults keeps these two layers separate.

The logical test describes what needs to be proven. The physical test describes how it is actually tested in the system.

That gives you a traceable line from the business risk to the test logic and eventually to the automation itself. Instead of opening an automation script three years later and wondering why it exists, you can still see the risk it was designed to cover.

Give the Agent more than one user story

Risk depends heavily on context, which is why the QA Risk Agent can also work with additional information such as user manuals, README files, release notes and other supporting documentation. These sources can be added as assets and used as evidence when the Agent analyses the system.

Consider a requirement that simply says:

A user can update their address.

On its own, the risk looks fairly limited. But another document might explain that the same address is consumed by invoicing, customer communications and regulatory reporting.

The requirement hasn't changed. The consequences of getting it wrong have.

That context is what turns generic test generation into useful risk analysis.

What happens when the requirement changes?

This is where one-off AI test generation becomes particularly awkward.

Suppose a banking requirement originally says:

Transfers above €10,000 require additional verification.

Three months later, it changes to €5,000.

You can feed the new specification into an LLM again, but now you have another generated output to compare with the first. Which risks are actually new? Which are the same but worded differently? Which existing tests are affected?

The QA Risk Agent is designed to treat specifications as something that evolves. When a revised specification is added, TestResults can distinguish between requirements that are unchanged, updated, superseded or new.

That allows the risk assessment to evolve with the product instead of starting from zero every time something changes.

There is also a technical challenge here: LLMs are probabilistic, while test management needs a degree of consistency. A significant part of the engineering behind the QA Risk Agent is therefore about adding deterministic behaviour around that probabilistic analysis. In internal evaluations against risk assessments created by human expert groups, the system has achieved 99.8% recall for identifying the risks represented in those assessments.

The goal isn't to generate an impressive answer once. It's to make the analysis useful over the lifecycle of the product.

Now decide what deserves automation

Only after the risks have been identified and prioritised, and the logical tests make sense, do we get to automation.

That's deliberate.

Large regression suites often become disconnected from the reasons they were created. A test exists because somebody added it two years ago. It runs because it has always run. Eventually it starts failing frequently, someone disables it and the dashboard goes green again.

Technically, the suite looks healthier.

In reality, you may have just lost coverage of an important business risk.

Linking tests back to risks makes that harder to ignore.

Automated tests remain linked to the risks they are intended to cover, making the purpose of the regression suite visible.

In our Notepad example, you can see two separate tests: one verifies that Undo correctly restores the prior state without corruption or a crash, while another verifies that deleted sensitive content cannot be restored across commit or reload boundaries.

Both are linked to the risks they mitigate.

Now the test isn't there simply because somebody thought “we should probably test Undo.” There is a visible chain from requirement → risk → logical test → automated test.

Exploration and automation belong together

The QA Risk Agent also doesn't assume that automation magically appears once you've generated a test plan.

Somebody still needs to understand the actual application.

You navigate through it, enter data, try different paths and see what happens. You explore the risky areas and discover which behaviours are worth checking repeatedly. TestResults uses that interaction as part of moving from the logical test into physical automation.

This brings exploratory testing and automation much closer together. The risk tells you where to look. Exploration helps you understand the real behaviour. Automation preserves the useful checks you want to repeat.

TestResults then uses its own computer vision model to interact with the visible application rather than relying on traditional UI locators. The analysis happens locally on the machine executing the test.

That becomes particularly useful for end-to-end enterprise processes where a test may need to move across different applications and technologies rather than staying inside one browser DOM.

AI is useful. The tester still has to think.

The QA Risk Agent can analyse specifications, find potential risks, retrieve relevant context, identify missing information and build logical test plans.

What it cannot do is understand your business better than you do.

And we don't want it to pretend that it can.

The tester still decides whether a risk is relevant. They can change its frequency or damage. They can reject a suggested risk, challenge an assumption, answer an open question and decide whether a test is worth automating.

One QA professional who saw an early version of the Agent summed up one of the biggest problems with AI-generated testing well:

“Who's reviewing it? Who's actually reading through it to understand whether it's a valid test or not?”

That is exactly the point.

Generating 200 tests in 30 seconds is easy. Knowing whether those 200 tests are worth having is still testing.

Meet the QA Risk Agent

The QA Risk Agent connects pieces of testing that are too often kept separate.

It starts with the specification, finds and prioritises the business risks inside it, turns those risks into logical test plans, surfaces missing information, connects the plans to physical tests and automation, and keeps that relationship intact as the specification changes.

The result isn't simply another way to generate more test cases.

It's a way to know why those tests exist in the first place.

Because before asking how much you can automate, there is a much more important question to answer:

What is actually worth testing? Check out the QA Risk Agent from TestResults and get your free risk score.