Guide
Validation Effort Should Follow Risk: Automated Tests Give You Evidence for Every Release
Volume of paper is not strength of evidence. We rank the paths where failure would matter and automate tests for them, so each release comes with results your quality unit can read.
4-minute read5 November 2026
In Brief
- Effort gathers where evidence is easy to produce, such as screenshots of menus, and not where a failure would reach a patient, a batch or a record. Each supplier release then restarts the cycle.
- We see four actions: rank the functions by consequence, script and trace the high-risk ones, test the low-risk ones lightly, and run automated tests on every change.
- Thinqmesh builds a plan for your key user journeys and automated tests that run on every change, then hands both to your team. Your first test suite takes four weeks.
A validation package for a modest system can fill binders with scripted steps and screenshots, a good share of them proving that a menu opens. Quality teams keep producing these packages because a thick file feels safe at inspection. Our view is that the volume has become a defect, because effort collects wherever evidence is easy to generate and seldom where a failure would hurt.
Regulators Have Long Allowed Effort to Follow Risk
FDA's 2003 guidance on Part 11 suggests that the decision to validate, and its extent, should take account of a system's effect on predicate rule requirements and on the accuracy, reliability and integrity of records, and it recommends a justified and documented risk assessment. FDA's Computer Software Assurance guidance develops that thinking, though it is written for medical device makers and not for drug manufacturers.
The practical consequence is that you may rank the work. Scripted, traceable testing goes where failure could harm a patient, a product or a record, and lighter testing goes elsewhere. Automated tests then keep that evidence repeatable on every change, so each supplier release comes with results and not with a new binder.
Four Actions That Put Validation Effort Where the Risk Is
Each one can be agreed with your quality unit before any further scripts are written.
Rank Each Function by the Consequence of Its Failure
Ask what would happen to a patient, a product or a record if the function failed.
Functions that touch the audit trail, a calculation or a release decision rank high. A menu, a layout or a report heading ranks low. Write the ranking down with its reasons, because a justified and documented risk assessment is what makes the lighter approach defensible.
Get started
- List the functions of one system and mark each high, medium or low.
- Write one sentence of reasoning for every high rating.
Script and Trace the High-Risk Paths
Where failure could harm a patient, a product or a record, keep scripted, traceable testing.
These are the paths where an inspector will want to see expected results, actual results and who ran them. Link each test to the requirement it covers, so the trace is readable in an afternoon.
Get started
- Pick one high-risk function and write its test steps and expected results.
- Link them to the requirement they cover.
Test the Low-Risk Paths Lightly
Where a failure would be visible and harmless, unscripted exploratory testing is enough.
A tester who explores a screen for an hour and records what was covered finds more than a long script of clicks. Keep a short record of what was tried, by whom and with what result.
Get started
- Choose three low-risk functions.
- Record a short exploratory session for each.
Run Automated Tests on Every Change
Repeatable tests give version-linked evidence and make supplier releases practical to adopt.
Automating the key user journeys means each release arrives with results tied to its version. Your team can then take supplier updates when they are ready and not defer them for the cost of re-testing.
Get started
- List the five user journeys you re-test most often by hand.
- Choose the first one to automate, and agree who maintains it.
How Thinqmesh Solves This
We begin by agreeing what must be tested on every release, based on what would cause the greatest harm if it failed. The tests are built into your release process, and people stay responsible for finding the unexpected.
- Week 1
Key User Journeys
We establish the key user journeys on your own software, ranked by the risk each carries for the business.
- Week 2
Test Design
Automated tests are written first for the paths that carry the most risk.
- Week 3
Connection to Release
The tests are connected to your release process, so that they run on every change.
- Week 4
A Suite in Use
Your team receives a working test suite whose results inform each release decision.
You finish with a test plan for your key journeys, automated tests running on every change, and a handover so that your team can extend them.
