User Acceptance Testing

For computer systems that do not require formal validation, at a minimum, user acceptance testing should be performed. This User Acceptance Testing should be outlined in a facility SOP, where the system is tested and assured to perform in the desired function effectively. The User Acceptance should be documented, and the system should be released for specific uses. 

Cmcial documentation needed in the development phase includes end-user manuals, a unit test summary report, a user acceptance test plan, results of the database design, results and methods employed in the source code evaluations, and a trace-ability analysis. A source code traceability analysis verifies that all code is linked to established specifications and established test procedures. 

Testable Criteria to be used for user acceptance testing must be specific, measurable, achievable, realistic, and traceable to the Fnnctional Specification and Design Specification. 

User acceptance testing occurs off-line in the QA environment. 

Operational Qualification (OQ) provides documented verification that a computer system operates according to written and preapproved specifications throughout all its specified operating ranges. OQ should only commence after the successful completion of the IQ. In short it comprises user acceptance testing, for it is necessary to demonstrate that the computer system operates in... 

More User Acceptance Testing (Qualification) Increment rigor of user testing commensurate with apphcation to improve confidence in software. 

The operational qualification is carried out after the IQ and is intended to demonstrate that the application works the way the suppher says it will. Most suppliers will supply OQ scripts. These, of necessity, will only cover a subset of functions and will not be a substitute for the user acceptance tests or PQ tests. 

In the test phase, user acceptance tests were performed. The goal of these tests was to verify whether the completed system was performing according to the user requirements dehned in the prequalihcation phase. Successful test completion was documented in the Vahdation Report, confirming that the system had been validated for use in daily business. Also included in this phase was the development of various operating procedures. The activities carried out are summarized below. 

User acceptance testing (often equated with Operational Qualification) of the application is also required against the functionality of the application s specification. 

The role of Performance Qualification, which entails challenging the application within the scope of business processes, is harder to distinguish. As a consequence PQ for databases may be combined with User Acceptance testing. Items for consideration within a PQ include verification of data management within the application (actually checking manipulated data sets to determine they are correct), and examining the role of the application within the wider process flow. 

As part of the validation activity, testing should be independently checked to confirm that it demonstrates traceability back to the corresponding requirement and that it verifies that the requirement has been met. For example, unit testing should verify that the design specification has been satisfied, system testing should verify that the FS has been satisfied, and user acceptance testing should verify that the URS has been satisfied. 

User acceptance testing (UAT) demonstrates that the application software meets the expectations of the user, based on the URS/functional description. It checks if the application software works in practice and is demonstrated by test cases/scenarios. 

User acceptance testing phase Operational Qualification (OQ) and reporting phase Performance Qualification (PQ) and reporting phase... 

User Acceptance Testing (UAT). UAT provides the pharmaceutical manufacturer with the final demonstration of computer system functionality. In the OCS, there will be confirmation that the individual systems operate as expected this will normally be a repeat of some or all of the tests in the supplier acceptance test specification. Following satisfactory demonstration of the individual systems, testing of the interfaces will be performed by the system integrator. Clearly the demonstration of the functionality in UAT is the same as is required for OQ testing, and the two activities should therefore run in parallel. The possible requirements for the on-site OQ are given in Table 6.3. 

Clinicians need to be able to view both the systolic and diastolic blood pressure values on the same graph concurrently. During user acceptance testing it was identified that the user could view one or the other parameter but not both at the same time. This functionality will be used by clinicians in approximately 50 % of consultations. The defect could compromise a clinician s ability to correctly interpret changes in blood pressure which could result in the delivery of incorrect clinical care. The issue would be easily detected by a trained user. 

The migration project is divided into the well-known phases of software development requirements analysis and specification, design and build, acceptance tests and productive go-live (Fig. 16.4). The acceptance test phase differs from the common software development cycle. It sphts into a phase of small batch tests which proofs the implementation to be compliant with specification and requirements and a test phase, which may be performed repeatedly or which may iterate over improvements of the specification, implementation and test phases. The tests try to identify the impact of the implemented migration solution on the complete source data set considered for migration. This approach requires a full dump of the source data to a separate stage solely dedicated to the test phase. This step proofs the assumption of the requirements phase to be correct and helps to identify anomalies or unexpected data in the source database. Thus, all data considered for productive migration need to be taken into account. The user acceptance test is... 

The whole medical IT network safety case (and indeed the health organisation safety policy) can be undermined by injudicious use of the proven capability argument where no real evidence exists to substantiate it. (This evidence would normally include past test reports, help desk problem records, operational IT metrics, user acceptance tests and other such historical IT project documentatiom)... 

---