What testing work can you hand to an outside team?

What do you hold at the end of each one?

• FDA validation

  Which FDA document governs your software, what the computer software assurance guidance excludes, and the protocol, executed record and traceability an investigator reads.

  Software inventory with an intended use written per feature, Process risk determination with its reasoning, Validation protocol with predetermined acceptance criteria, Executed validation record per item, Traceability matrix from requirement to executed result, Electronic record and signature test results, Change assessment and re-validation decision log

• Data migration testing

  Testing a healthcare data migration while the source system can still be read: mapping, reconciliation, coded history, and what happens to the platform being switched off.

  Mapping specification with one rule per field and per relationship, Pre-cutover reconciliation record, run while both systems answer, Coded content revalidation report keyed to the date of service, History and linkage inventory covering corrections, superseded results and appended material, Designated record set inventory restated for the target estate, Source system disposition record, Defect record separating a load defect from a source defect

• Mobile app testing

  What mobile app testing produces when the software runs on a device you do not own: the platform states exercised, the WCAG 2.1 touch criteria, and a use environment you can evidence.

  Platform matrix with the rationale for what it represents, Handset-state run records, each naming the state and the build, Written determination for each addressable specification exercised, WCAG 2.1 results per screen and per responsive variation, Use error and use difficulty log with root causes, Scoping record for platform-supplied parts of the interface, Platform release register tied to verified builds

• QA outsourcing

  What HIPAA obliges an outsourced QA arrangement to contain, which questions it leaves entirely to you, and the artefacts an engagement produces.

  Permitted use statement for the test estate, Named access register, per person and per subcontractor, Data reach map of the working artefacts, Incident awareness log, Exit disposal statement, Test asset handover pack

• Test automation

  Why a suite that produces quality records is itself software carrying a validation obligation, what an automated run record has to name, and what a framework upgrade reopens.

  Intended use written for each job in the pipeline, Assurance record for the tooling that produces the evidence, Run record naming the version tested, the configuration, the test tools and the responsible person, Register of which requirements the suite is allowed to close, Repeated-run log with the disposition of each attempt, Tooling change assessment for the framework, the runner, the drivers and the reporting step, Environment and test data rule for the suite

• HIPAA testing

  What a HIPAA testing engagement hands over when the rule issues no certificate: the addressable specification register, the safeguard evidence, and the records an investigator asks for.

  Addressable specification register, Evaluation evidence pack for 164.308(a)(8), ePHI access route inventory, Individual rights execution report, Professional judgment routing evidence, Six-year retention map

• Interoperability testing

  Testing a healthcare integration against the partner systems it has to work with: HL7 v2 profiles, FHIR R4, DICOM, and the versions each exchange is pinned to.

  Interface inventory with one specification per interaction, Capability claim reconciliation report, Validation reports per interface, each tied to a named build, Optionality and local extension register, Version and adopted period matrix, Partner defect record naming the side each finding falls on

• Device software testing

  What medical device software testing produces, how the safety class changes the depth per software item, and which records an assessor can open a year later.

  Test plan written against the risk management plan, Scope statement per software item, with the class it was tested to, Two-way trace between hazards and executed runs, Executed run records carrying the build and artefact identifiers, Risk control effectiveness evidence, filed apart from implementation evidence, Change impact rule, stating which classes of change reopen which runs

• PHI security testing

  What healthcare penetration testing attaches to when the Security Rule names no technique: the risk analysis at 164.308(a)(1)(ii)(A), the evaluation at 164.308(a)(8), and the record behind a finding.

  Finding register keyed to Subpart C sections, Risk analysis input pack for 164.308(a)(1)(ii)(A), Risk management decision log for 164.308(a)(1)(ii)(B), ePHI egress map, Test window and attribution record, Contingency exercise report for the 164.308(a)(7) plans

• Validation documentation

  What a validation record has to prove, why the traceability matrix is the artefact that finds the gaps a passing test run hides, and which document an assessor opens first.

  Bidirectional requirements traceability matrix, Validation plan with acceptance criteria fixed before execution, Test protocols written against your requirement identifiers, Executed records with attributed signatures, Coverage and orphan report, Deviation log with disposition and retest evidence, Evidence cross-reference index