How should an EDC study build be tested before go-live?

Why

EMA's computerised systems guideline treats trial specific configuration as something to pre-specify, verify against the protocol and data management plan, and test before release to production. It asks for traceability from each requirement to a test, pre-approved test cases stating the software version, prerequisites, steps and expected result, and recorded actual results with evidence. Where possible the tester should not be the author of the test case.

User acceptance testing involves the people who will use the system, because they spot problems specifications miss, such as a visit window that cannot be entered for real dosing schedules. Testing should focus on critical functions: eligibility forms, randomization or IRT links, primary endpoint fields, SAE forms and the edit checks on them. A protocol amendment that changes forms triggers the same process, and the team decides whether new fields apply to all participants or only those enrolled after the amendment.

How to work it through

1. List requirements from the protocol, schedule of assessments and data management plan.
2. Rank them by risk so critical functions get the deepest testing.
3. Write and approve test cases with expected results before testing starts.
4. Execute in a test environment, recording actual results and screenshots for each step.
5. Log and assess every failure, fix it, and retest, including regression tests on related functions.
6. Obtain sign-off and release to production with the tested version recorded.

Where the answer stops holding

Testing cannot prove a build is error free, only that tested scenarios work. Vendors' platform validation covers the software, not the sponsor's study configuration. Tight timelines tempt teams to test only the happy path, which misses the edge cases where real data break checks.