16. Why Document System Testing?

Formal testing is performed in a documented manner that is traceable back to a management approved unique requirement or specification item…Testing without formal documentation is meaningless for audit and inspection purposes and a waste of precious resources for GXP systems. (p.89)

 

The first document in formal testing is a management approved requirements document. If you don’t know just what your system is supposed to do and deliver, then there is no way to be sure you have tested it well enough to know that your system operates reliably and consistently to meet your regulated work process needs. Testing without defined requirements to test against is an aimless exercise and an expensive waste of time and resources.  Suppliers need product, functional, and design specifications for testing. IT departments need user and infrastructure requirements defined. End users need their GXP work process requirements defined for the data handling and process control functions the system needs to perform. Requirements for security, error handling, and range of operational limits are also included and tested for in each set of requirements.

The number one reason for documented testing is to ensure that your GXP system consistently operates as expected for its regulated tasks across the functions your work process needs in its operational environment. Included in this is negative and stress testing to show that the GXP system can protect itself, its data, and any control operations from expected issues arising in its operating environment.

The second reason for documented testing is to provide evidence of the GXP system’s performance in your work process, operating conditions, and infrastructure environment. Included in this is evidence of the scope of testing to show that you checked all your defined requirements for the system. This answers the question from your management, “Did we get the right system for our business needs?”

The third reason for documented testing is to provide evidence for auditors and inspectors of GXP systems. Without documented test evidence, your GXP system will not get credit for the testing you performed on it and it will fail the audit or inspection. One business goal for documented formal testing is to achieve “uneventful” audits and inspections.

It is important to remember that formal testing includes more than just requirements and test scripts. Auditors and inspectors look for the following formal test documentation:

• Uniquely Identified Requirements to cover the GXP work process and system function needs,
• Test Plan to describe the approach to testing, features not tested, and tasks required,
• Test Scripts grouped in some logical manner based on work process and system functions,
• Trace Matrix to show which test scripts were used for each requirement, and
• Test Summary Report to describe what actually happened, issues arising and their resolution, people and roles participating, and recommendation for system status based on test results.

 

Next Month: Why can’t IT write a good system URS by itself?

Developing a good URS requires high expertise in the work process to be computerized, not in the computer technology itself. (p.40) Developing a well-considered URS is the first step in the successful purchase of a new GXP system. (p.41)