Test record
Remote monitoring app · build 3.2.0
Reviewed by a personLinked to requirement and build
Healthtech testing
Your engineers are also your QA team. That is the problem.
When product work moves quickly, testing becomes another responsibility for the people building the release. We take on the agreed test work, and the record it produces answers whoever asks next: an NHS buyer, an investor, or a clinical-safety or lifecycle review.
20-minute call · proposal within one working day · no patient data needed
Illustration. Example values from a fictional project, not a client engagement.
The testing gap
Clinical software does not fail
only when it stops working.
The harder failures arrive when a critical workflow was never exercised, a change has no clear re-test trail, or the people asked to explain the product did not run the work themselves.
Nobody owns it
Testing is shared across engineers, product people, and busy clinical stakeholders. It happens when there is time, not as a visible piece of release work.
Evidence is rebuilt from memory
When a buyer, reviewer, or clinical-safety conversation begins, the team has to reconstruct which version was tested, what changed, and why it was acceptable.
Failures are quiet
Edge cases around access, clinical workflow, permissions, data, and recovery can sit unnoticed because the everyday path still appears to work.
The practical answer
We test the product.
The evidence is a by-product.
AI Test Group takes responsibility for the agreed test work. We test the product as it is actually used, record the findings against the build, and keep the trail clear as issues are fixed and re-tested. Every agreed scenario is reviewed by a person.
We run the testing and produce the evidence. Your team gives us access to the product, clinical and product input when we need it, and fixes for what we find.
See the full timeline
What the testing covers
The whole test surface, not only the regulated part.
Most teams arrive for one release or one review, then keep us for the rest.
Functional and regression
The clinical journeys that must keep working every release, such as booking, prescribing and results, including the ones nobody has re-run since launch.
Integration and data
Interfaces, mappings and identity matching, and the handoffs where a patient record changes hands and a field can quietly drop.
Mobile and device
Real phones and tablets, not emulators: permissions, notifications, and the background limits that stop a reading syncing overnight.
Resilience and real conditions
Weak signal, interrupted sessions and a service that is unavailable, and what a clinician sees when it happens.
Accessibility and usability
Keyboard paths, screen readers, contrast and error messages, on the screens where a misread value carries clinical risk.
Whatever we test, each test is traced to the hazard or requirement it verifies, so it counts as evidence, not just a pass.
Before you open a QA role
Why not just hire a tester?
A hire solves one problem. We take the testing, the clinician and the evidence off your engineers together.
Start in two weeks
A clinician on the team
Evidence from day one
Led by 20+ years of regulated QA
Our team is led by more than twenty years of testing on NHS and central government programmes, where the evidence had to stand up to scrutiny. That experience runs every engagement.
Scales with your releases
When the product uses AI
A model update is a change your evidence has to answer.
If your product uses a model, its behaviour can move without a line of your code changing. Edge cases shift, failure modes shift, and the scenarios your controls were verified against stop describing the system you are running. We test model behaviour the way we test everything else: scenarios written down, run against a stated version, and run again when the model underneath moves.
When someone asks for proof
The same record answers more than one question.
The record is built once, then shaped for whichever question arrives first.
-
Buyer
An NHS or enterprise buyer
Safety and quality questions arriving in the middle of a sale, usually with a deadline attached.
-
Diligence
Investor or acquirer diligence
A technical reviewer asking who decided the release was safe, and what evidence exists that it was.
-
DCB0129
Selling into the NHS
Your NHS buyer will ask for a signed safety case. We produce it: the hazard log, the Clinical Safety Case Report and our in-house CSO’s signature, with every control backed by a test on your real product.
Explore DCB0129 -
IEC 62304
Building a medical device
Your notified body will ask to see every requirement verified. We run the tests on your build and hand you the traceable record, from safety classification to technical-file index.
Explore IEC 62304
Not facing any of these yet? That is the cheapest time to start the trail, because nothing has to be reconstructed later.
See what you receiveWho this is for
Built for teams who
Need testing that keeps up with the product.
- Are releasing clinical or health software and want the testing owned
- Have no QA function, or a QA team that cannot cover every release
- Need a record that survives a buyer, an investor or a review
- Want the testing done, not a report telling you to do it
Less suited if
You only need a generic test list.
- You want a self-serve test tool rather than a team that owns the testing
- You need a notified body, product classification or conformity assessment
- You need extra manual testers rather than an evidence trail
If you need a standards route, the next question is whether the product needs DCB0129, IEC 62304, or a discussion first. Building a non-clinical wellness product? Wellness testing is here →
AI Test Group is not a notified body. We do not certify or approve anything. We do not determine whether a product is a medical device. The manufacturer’s accountable signatory signs the safety case.
Questions healthtech teams ask
Before you hand testing to someone else.
Will a person review every scenario?
Yes. Every agreed scenario is designed, executed, and reviewed by a person. Automation may support repeatability where useful, but it does not replace judgement about product behaviour or the evidence record.
Can you use our existing tests and documents?
Yes. We review what already exists, identify what is attributable to the current product version, and focus the work on the gaps that matter for the agreed scope.
Do you need real patient data?
No. We never ask for patient data, and we do not work with it. Testing runs against synthetic data in your test environment.
Who owns the test material at the end?
You do. The evidence, the records and the test material are yours.
Do you provide Clinical Safety Officer support?
Where it is included in scope, AI Test Group provides in-house Clinical Safety Officer support. The manufacturer remains accountable for its product and the appropriate sign-off.
Our product is not a medical device and we have no standard to meet yet. Is this still for us?
Yes. Most of the work is testing the product properly and keeping a record of what was tested against which version. That record is worth having on its own, and it is what a standard, a buyer or an investor asks for later.
How quickly can a Compliance Sprint begin?
A Compliance Sprint runs for two weeks from kickoff once product access, the test environment and the relevant team input are available.
Start with a Compliance Sprint.
Two weeks, fixed scope, on your real product and your highest-risk area. You keep everything it produces, and there is no lock-in.