The quality and accuracy of the validation testing is directly related to the quality and accuracy of the documents the testers are provided with to generate the test scripts. Poorly designed specifications lead to poorly designed protocols. There are two major systems specification documents required in any computerized system.

• The functional design specification
• The Design Specification or the User Requirement specification

The functional specification explain in specific detail, how the system will meet the business needs of the end user. The design specification documents in specific detail using non-technical terms, how the computer system will meet the requirements as defined in the functional specification.

So for example in the functional specification you may see something like:

The system must allow four distinct levels of user access.

• Trainee
• Operator
• Manager
• System Administrator

In the detailed design specification you would see the screens, fields, error messages, and logic necessary to implement Multiple Levels of User Access.

A lot of companies test the basic screen functionality, but omit field–level testing. Understand that it is a regulatory requirement to have Field-Level testing with invalid, valid, borderline, and special-case data, and that functional verification with invalid scenarios, error message checking, and logic challenges are a regulatory expectation.

Minimally, the tester needs all field information for all cGxP fields, screen information for all screens that contain at least one cGxP field including the error messages and logic for that screen, and where this screens functionality falls in relation to the functionality of the entire module.

How do you determine if a field is a cGxP field

Here’s a simple explanation, if by any stretch of the imagination the safety or efficacy of the product can be compromised because of a problem in this field then it is a cGxP field.

What kind of field information is needed in order to be able to create comprehensive tests for a cGxP field?

The following information maybe required:

• Field Name
• Field Description
• Field Length
• Field Type (Drop Down List, Input, Read-Only)
• Data Type (Numeric, Alphanumeric, Date)
• Data Range (Yes/No, Positive Integers, Days of the week, Monday-Friday)
• Required/Optional Status of Field
• Field Logic and Error Messages
• Any associated Field Logic or Error Messages associated with this field
• Any rounding or truncation done on the field, or any calculations related to this field
  Hidden/Unhidden status, if applicable
• The quality of information available on that feature screen
• The experience of the test writer

Non-existent or inadequate Life-Cycle documentation

For years now the FDA have been cracking down on lack of adequate documentation and design materials, because the presence of adequate specifications is how quality is built into the system. Quality is not built into the system by having the QA department present during the life cycle development.

It is built into the system by having the QA department beat the developers over the head to force them to generate adequate specs, and in the process, the Developers will ask a lot of questions that haven’t been asked, and/or make a lot of assumptions about how an end user will want things to look. And many of their assumptions will be wrong, because they are developers and not end users. The process of having the developers document their design and having the developers document their design and having the end users sign off on it, opens communications between the two when the end users come back with “It can’t look/work this way”

Defense programming and the QA group

In the world of defense programming, there isn’t even a QA group. One isn’t needed. Good requirements and design specifications, signed off on by the clients, are all that is needed to build quality into the system. These specifications can’t be substituted for by the presence of QA or a wonderful Quality Manual. Any systems that don’t have adequate specifications can’t be substituted for by the presence of QA or a wonderful Quality Manual.

Any system that doesn’t have adequate specifications is in danger of not having quality built into them and they are out of compliance with current industry and regulatory standards. This is the main reason that many companies have received FD-483’s for systems that have no life cycle documentation.
The adequacy of a computer validation is measured by conformance to standards at all stages of the lifecycle.