eCRF configuration testing
eCRF configuration testing checks that a design version behaves as the specification requires: every data check fires where it should, display conditions hide and show fields correctly, derivations compute correctly. It is a step in the lifecycle of every design version, amendments included: testing → review → approval → publication.
The module does not address validation of the X7 system — its status is set by the customer’s documents.
Open testing from a design version: Study design → the version’s “⋯” menu → eCRF configuration testing, or from the link in the checklist of a version in review.
Required coverage
Section titled “Required coverage”First set the risk of each form under your organisation’s SOP — it decides the coverage its rules require:
| Risk | Requirement for every rule of the form |
|---|---|
| High | confirmed positive and negative cases |
| Medium and Low | at least one confirmed case |
Write the rationale for the risk — it goes into the report.
Working with cases
Section titled “Working with cases”-
Click Find cases. For every rule the engine tries boundary and equivalence values and finds an input where the rule fires and one where it does not. The expectation of such a case comes from the engine itself — it is only a draft: it gives no coverage.
-
Add your own cases: Add a case on a rule — values are entered by field name, the expected outcome comes from the specification.
-
A case is confirmed by another person, not its author: they check the input and the expectation against the specification and click Confirm. An unconfirmed case counts at no risk level.
-
Click Run tests: every case is executed by the same rules engine as data entry, without subject data. The run records who started it and the design fingerprint (SHA-256).
-
Download the Test report.
Link to version approval
Section titled “Link to version approval”A run of a draft or of a version in review is recorded as evidence on the version. The approver sees in the checklist whether there is evidence with the criteria met for the current design. Without it (the design changed after the run, the criteria are not met, or testing was done outside the system) the version can be approved only with a reason — the reason and the fact of approval without evidence stay in the audit trail.
An amendment is a new design version and goes the same way: the version diff shows which rules changed and what needs retesting.
Test report
Section titled “Test report”The report is built only from the latest run and prints to PDF from the browser: document properties with the design fingerprint, purpose and scope, required coverage and form risk, summary, rules and their coverage, deviations (failed cases and rules without the required coverage), test acceptance criteria, outcome and the “Prepared by / Reviewed by / Approved by” signature lines.
The outcome reads “the test acceptance criteria are met” or “are not met”. Whether the configuration is fit for use is decided and signed by the sponsor’s responsible person. If the design changed after the run, the report says plainly that the results are outdated.
Permissions
Section titled “Permissions”- View configuration testing — see the screen and download the report;
- Maintain configuration testing — set risk, keep and confirm cases, run tests.
Every module action is recorded in the audit trail.