A test case an AI wrote still has to be read and released by a person. A green run proves only that the code runs – not that it checks the right thing. A generated test case nobody reads is not evidence, so reviewing and releasing it is the point, not the speed. And in the audit the question still comes up: who reviewed and released this one?
The difference
In a regulated context this is no small thing
In web and app development a bad generated test is a nuisance – you notice it at the next bug and fix it. In a medical device or a safety-related controller it breaks the chain of verification: the evidence that a requirement was tested rests on the test case checking the right thing and on someone having confirmed it. An unread AI test case provides no such foundation.
What is common today
Generated code nobody reads does not hold
The common path: the AI produces Python or Robot code, a developer skims it, the run goes green. Two problems remain. First, quality assurance and regulatory can’t read that code – the people who sign in the audit see a black box. Second, there is no evidence that anyone reviewed it at all. A significant share of AI-generated test cases needs rework before it is any good – but a green run doesn’t show whether that rework happened.
The mechanism
Blocks instead of code, a release with a fingerprint
XPressRT turns it around. The AI writes no code, it places blocks – each block a sentence a person reads. If a block is missing for what a step needs, the AI stops and says which one; it doesn’t build its own. XPressRT turns the blocks into the executable step.
And the release carries a fingerprint: it records who released which step, with the fingerprint of the blocks and of the code generated from them. If anything changes afterwards, the fingerprint no longer matches. A signature can’t be forged after the fact.
Tool qualification
Qualify the building blocks once, then only the order
Because the building blocks are fixed and qualified once, the review shifts: not every generated test case has to be verified from scratch, only its composition – the order of readable blocks that a person can follow. That is the basis on which tool qualification can be carried, instead of starting over on every AI run.
Frequently asked questions about AI-generated test cases
Who releases an AI-generated test case?
A person – quality assurance or regulatory. In XPressRT they read the blocks (each a sentence, not code) and release them. The release is recorded with a fingerprint of the blocks and of the generated code.
How do I document the review of an AI test case?
Through the per-step release: who released, when, and with which fingerprint. If anything changes on the test case afterwards, the fingerprint no longer matches – the signature can't be forged after the fact.
Are AI-generated tests compatible with IEC 62304?
Yes, when the review and release are evidenced. The standard does not require a particular way of generating tests, but documented evidence that the test checks the right thing and was released. That is exactly what the readable-blocks-and-release mechanism provides.
Is this another AI test tool or a tool comparison?
No. This is not about test-case generation, self-healing or prompt tips, but about one question: how does an AI test case become readable, reviewable and releasable – so that it holds in an audit.
The audit-ready way to use AI
The building-blocks-and-release mechanism sits in XPressRT, the test software for system tests on the device. In the browser, no installation and no account – open it and see how an AI test case becomes readable, reviewable and releasable.