How to test a clinical trial management software
Direct answer
Shipped untested, clinical trial software allocates a participant from the wrong randomisation table or dispenses the wrong kit from a weight-based dose, and lets a primary-endpoint value change with no audit trail entry, reason or e-signature, in the randomisation and eCRF entry flows. 10 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with penetration testing: a blinded site user and a sponsor monitor must both fail to read the treatment arm or another site's participants by changing ids.
10 mandatory testsfirst: penetration testing
What counts as a clinical trial management software
Clinical trial software here means web and API systems for electronic data capture and trial operations used by sponsors and study sites, including randomisation, drug supply and imports from labs, eCOA and devices. It counts when the system holds data submitted to a regulator or identifiable participant data. A hospital record system used for treatment is out of scope, and so is a consumer health app that is not part of a study protocol.
Adjacent product types not covered here
- electronic health record system: A record system routes orders for treatment, while trial software holds study data under audit trail, e-signature and validation rules.
- software as a medical device: Software as a medical device produces a dose or alarm for one patient under a device clearance, not randomisation and blinding across study sites.
- patient portal: A patient portal shows a patient their own record, while trial software must keep the treatment arm hidden from blinded users.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Physical or psychological harm to a user user-harm | harm | primary | A participant entered in an untested stratum combination is allocated from the wrong randomisation table, or the weight-based dose calculation dispenses the wrong kit. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | An inspector asks who changed a primary-endpoint value at a site, and the eCRF shows the new value with no audit trail entry, reason or e-signature. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | A sponsor monitor exports subject listings and the file carries participant names and dates of birth from the site's source upload instead of subject IDs. | |
| Records silently wrong data-corruption | data | primary | A hosted eCOA or EDC loses trial data or its audit trail during a change, so endpoint data can no longer be verified against source. | |
| Third-party dependency fails dependency-failure | outage | primary | The hosted randomisation service is down during a site visit and the investigator cannot randomise or emergency-unblind a participant, with no documented fallback. |
Mandatory tests (10)
Step 1: release smoke tests
Why:data-corruptionregulatory-penalty
Done when: After each deployment to production, a test site enters, edits and signs one eCRF page, and the audit trail shows the old value, new value, user, time and reason.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: penetration testing
Done when: A blinded site user and a sponsor monitor each try to read the treatment arm or another site's participants by changing ids, and both attempts fail.
Tool class: proxy. Who usually runs it: security specialist.
Step 3: unit tests
Why:user-harm
Done when: Every combination of randomisation strata allocates from the expected table, and dose calculations match the protocol table at each weight boundary.
Tool class: unit framework. Who usually runs it: developer.
Step 4: end-to-end functional tests
Why:user-harm
Done when: A test participant is screened, randomised, assigned a kit and emergency-unblinded by the investigator, and only the investigator and named unblinded roles see the arm.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 5: regression suite
Why:regulatory-penaltydata-corruption
Done when: Before each release, the validated scripts for edit checks, signatures and audit trail rerun and pass on the release candidate, and the result is filed in the validation package.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 6: data integrity and migration testing
Why:data-corruptionregulatory-penalty
Done when: After a protocol-amendment migration, a reconciliation report shows every subject, visit and value matches the pre-migration export, and audit trails are carried over unchanged.
Tool class: data validation. Who usually runs it: QA engineer.
Step 7: compliance checks
Done when: A signed validation package maps each Part 11 and GCP requirement (audit trail, e-signature, access control, retention) to a test record an inspector can open.
Tool class: test management. Who usually runs it: QA engineer.
Step 8: integration tests
Why:data-corruption
Done when: Lab, eCOA and device files imported into the EDC land on the right subject and visit, with the same values and units as the source file.
Tool class: API client. Who usually runs it: developer.
Step 9: security scanning
Why:data-breach
Done when: The scan report for the EDC and its export endpoints shows no open high-severity finding, and a deactivated site user cannot sign in.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 10: resilience and failure testing
Done when: With the randomisation service switched off in staging, the site follows the documented fallback, and entries made during the outage appear with correct timestamps after recovery.
Tool class: chaos tool. Who usually runs it: developer.
Recommended and optional tests
exploratory testingrecommended
Becomes mandatory when a study uses adaptive randomisation or complex eligibility.
contract testsrecommended
Becomes mandatory when a study uses more than one external data provider.
localization testingrecommended
Becomes mandatory when participants complete questionnaires in more than one language.
offline and poor-network testingrecommended
Becomes mandatory when participants enter data on devices outside the site.
accessibility testingrecommended
Becomes mandatory when participants enter data themselves through a public-facing portal.
usability testingoptional
May help: site coordinators make fewer query-generating entry errors on clear forms.
performance and load testingoptional
May help: shows whether database lock and a full-study export finish while sites keep entering data.
Not needed and why
device and browser compatibility
Not needed: site users work on a defined browser list in the validation package. Becomes recommended when participants use their own phones for eCOA.
analytics and event tracking tests
Not needed: no product analytics decide anything in a validated trial system. Becomes recommended when a participant-facing app adds usage tracking.
Order of work
First release
- release smoke tests: After each deployment, enter, edit and sign one eCRF page at a test site and check the audit trail shows the old value, new value, user, time and reason.
- penetration testing: Have a blinded site user and a sponsor monitor try to read the treatment arm or another site's participants by changing ids.
- unit tests: Run every combination of randomisation strata against the expected allocation table and every weight boundary against the protocol dose table.
- end-to-end functional tests: Screen, randomise, assign a kit to and emergency-unblind a test participant, and confirm only the investigator and named unblinded roles see the arm.
- regression suite: Rerun the validated scripts for edit checks, signatures and audit trail on the release candidate and file the result in the validation package.
- data integrity and migration testing: Migrate a test study through a protocol amendment and reconcile every subject, visit and value against the pre-migration export, with audit trails carried over unchanged.
- compliance checks: Map each Part 11 and GCP requirement for audit trail, e-signature, access control and retention to a test record an inspector can open, and sign the validation package.
- integration tests: Import lab, eCOA and device files and confirm each value lands on the right subject and visit with the same value and units as the source file.
- security scanning: Scan the EDC and its export endpoints, clear every open high-severity finding, and confirm a deactivated site user cannot sign in.
- resilience and failure testing: Switch off the randomisation service in staging, follow the documented fallback, and confirm entries made during the outage carry correct timestamps after recovery.
Ongoing cadence
- release smoke tests: After each deployment to production.
- regression suite: Before each release of the validated system.
- data integrity and migration testing: Before each protocol-amendment migration.
- unit tests: When a protocol changes its strata, randomisation tables or dose tables.
- integration tests: When a lab, eCOA or device provider changes its file format.
- compliance checks: When Part 11 or GCP guidance changes, or the validation package is updated.
- resilience and failure testing: When the hosted randomisation service or its documented fallback changes.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of clinical trial management software (web, api). Not recommendations.
release smoke tests
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
unit tests
end-to-end functional tests
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
data integrity and migration testing
- dbt testsTests on warehouse models inside dbt. apiopen-source
- Great ExpectationsData validation with declarative expectations. apiopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- pytestTest framework for Python with fixtures and plugins. apiopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- GarakProbing LLM applications for prompt injection and leakage. apiopen-source
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
- TrivyScanner for containers, dependencies and configuration. apiopen-source
resilience and failure testing
- Chaos MeshFault injection for Kubernetes. apiopen-source
- GremlinManaged fault injection. apicommercial
- ToxiproxyTCP proxy for simulating network failures. apiopen-source
contract tests
- PactConsumer-driven contract testing with a broker. apiopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
localization testing
- Lokalise QATranslation management with in-context review. webiosandroidcommercial
offline and poor-network testing
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- ToxiproxyTCP proxy for simulating network failures. apiopen-source
accessibility testing
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for clinical trial management software has the same 10 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the clinical trial software is accepted when an edited and signed eCRF value shows the old value, new value, user, time and reason in the audit trail, and the validated scripts pass and are filed in the validation package. Every randomisation stratum allocates from the expected table, blinded users cannot read the treatment arm, and imported lab, eCOA and device values land on the right subject and visit.
Brief
# Test brief: clinical trial management software Product type: clinical trial management software. Electronic data capture and trial operations for sponsors and sites. Risk map and evidence: https://howtotestaproduct.com/how-to-test/clinical-trial-software/ Printable checklist: https://howtotestaproduct.com/checklists/clinical-trial-software/ Run these 10 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: data-corruption, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer. Done when: After each deployment to production, a test site enters, edits and signs one eCRF page, and the audit trail shows the old value, new value, user, time and reason. 2. penetration testing (risks: data-breach, user-harm). Tool class: proxy. Usually run by: security specialist. Done when: A blinded site user and a sponsor monitor each try to read the treatment arm or another site's participants by changing ids, and both attempts fail. 3. unit tests (risks: user-harm). Tool class: unit framework. Usually run by: developer. Done when: Every combination of randomisation strata allocates from the expected table, and dose calculations match the protocol table at each weight boundary. 4. end-to-end functional tests (risks: user-harm). Tool class: browser automation. Usually run by: QA engineer. Done when: A test participant is screened, randomised, assigned a kit and emergency-unblinded by the investigator, and only the investigator and named unblinded roles see the arm. 5. regression suite (risks: regulatory-penalty, data-corruption). Tool class: browser automation. Usually run by: QA engineer. Done when: Before each release, the validated scripts for edit checks, signatures and audit trail rerun and pass on the release candidate, and the result is filed in the validation package. 6. data integrity and migration testing (risks: data-corruption, regulatory-penalty). Tool class: data validation. Usually run by: QA engineer. Done when: After a protocol-amendment migration, a reconciliation report shows every subject, visit and value matches the pre-migration export, and audit trails are carried over unchanged. 7. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: QA engineer. Done when: A signed validation package maps each Part 11 and GCP requirement (audit trail, e-signature, access control, retention) to a test record an inspector can open. 8. integration tests (risks: data-corruption). Tool class: API client. Usually run by: developer. Done when: Lab, eCOA and device files imported into the EDC land on the right subject and visit, with the same values and units as the source file. 9. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan report for the EDC and its export endpoints shows no open high-severity finding, and a deactivated site user cannot sign in. 10. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer. Done when: With the randomisation service switched off in staging, the site follows the documented fallback, and entries made during the outage appear with correct timestamps after recovery. Acceptance criteria wording: A release of the clinical trial software is accepted when an edited and signed eCRF value shows the old value, new value, user, time and reason in the audit trail, and the validated scripts pass and are filed in the validation package. Every randomisation stratum allocates from the expected table, blinded users cannot read the treatment arm, and imported lab, eCOA and device values land on the right subject and visit. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a clinical trial management software
What testing does clinical trial management software need?
10 mandatory tests cover the 5 risks in the map: eCRF changes with no audit trail, trial data or audit trails lost during a system change, wrong randomisation or dose, identifiable data in sponsor exports, and a randomisation service outage with no fallback. They run as release smoke, penetration, unit, end-to-end, regression, data integrity, compliance, integration, security scanning and resilience tests.
How is the audit trail tested in clinical trial management software?
The release smoke test edits and signs one eCRF page after each deployment and checks the audit trail shows the old value, new value, user, time and reason. The regression suite reruns the validated audit trail and signature scripts before each release. The data integrity test confirms audit trails carry over unchanged after a protocol-amendment migration.
Which tests in a vendor test plan for clinical trial management software are not needed?
Compatibility and analytics tests are marked not needed: site users work on a defined browser list in the validation package, and no product analytics decide anything in a validated trial system. Compatibility becomes recommended when participants use their own phones for eCOA.
What is the minimum testing for clinical trial management software at MVP stage?
Once any live study runs on the system, the 10 mandatory tests apply, because each is tied to a risk in the map. The data integrity test applies while studies change protocol versions mid-study, and the integration test applies while data arrives from external labs, eCOA or devices.
What should I send to the person who will test clinical trial management software?
Send the 10 mandatory tests with their done conditions, a staging study with test sites, and the randomisation and dose tables from the protocol. Include the validation package the regression and compliance results are filed in, and the documented fallback for a randomisation service outage.
Evidence
ev-0054regulatorprimary
Guideline on computerised systems and electronic data in clinical trials (EMA/INS/GCP/112288/2023), European Medicines Agency, GCP Inspectors Working Group
Where the randomisation is stratified by factors inputted by the user, all the combinations of the strata should be tested to confirm that the allocation is occurring from the correct randomisation table.
EMA inspectors expect trial systems to keep a secure audit trail, restrict unblinded data to named roles, test emergency unblinding and test randomisation strata and dose calculations in response technology, which covers data corruption and participant harm in trial software.
published 2023-03-09 · verified 2026-10-07
ev-0033regulatorprimary
21 CFR Part 11: Electronic Records; Electronic Signatures, U.S. Electronic Code of Federal Regulations
Part 11 requires validation, audit trails and signature controls for electronic records submitted to or kept for the FDA.
published undated · verified 2026-10-07
ev-0053regulatorprimary
Warning Letter: Applied Therapeutics, Inc. (MARCS-CMS 696833), U.S. Food and Drug Administration
FDA cannot verify the accuracy, consistency, and completeness of study data collected for critical eCOAs
A sponsor received an FDA warning letter after a contracted electronic outcome assessment system had trial data and its audit trails deleted, so the endpoint data could not be verified; this is the record-retention failure trial software must prevent.
published 2024-12-03 · verified 2026-10-07
ev-0055regulatorprimary
Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers, U.S. Food and Drug Administration
Final FDA guidance (issued October 2024 per the page) on how sponsors, investigators and service providers meet Part 11 for electronic systems, records and signatures used in clinical investigations, the rule set an EDC or CTMS is inspected against.
published undated · verified 2026-10-07
ev-0025regulatorprimary
Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union
The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.
published undated · verified 2026-10-07
ev-0056standardprimary
ICH E6(R3) Guideline for Good Clinical Practice, Step 5, International Council for Harmonisation, published by the European Medicines Agency
Contingency procedures should be in place to prevent loss or lack of accessibility to data essential to participant safety, trial decisions or trial outcomes.
The GCP standard requires trial systems to survive system failure without losing or locking away safety and outcome data, which makes a hosted EDC or IRT outage a trial-level risk.
published 2026-07-14 · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.