Over the last few weeks on our forum, a debate surrounding the best way to create an equipment qualification test script has taken place, with various different members offering their insight into the best fields to use to capture all of that important test data.

This article will try to represent the most common themes that emerged from the debate and outline the most common practices seen in the industry today.

VIEW THIS VIDEO BELOW BEFORE READING THE ARTICLE

                       

Objective

The objective section of the test protocol details what exactly is the objective of the test, in other words why are we performing this test. This section should explain in detail why the engineer is carrying out the test and what they should achieve by doing so.

Example:

• The objective of this test is to verify and document that the test equipment/instruments used during the protocol execution (e.g. multimeter) are identified and verified to be calibrated.
• To test all trips, interlocks and alarms work correctly.
• To test all error messages associated with the system.
• Confirm that there are no unaccounted changes to program parameters or data saved prior to the sudden loss of power.

Test Procedure

Quite simply the test procedure should detail what procedure needs to be followed in order to execute the protocol correctly. This section should guide the engineer and give them an overview as to how the test should be performed.

Examples:

• All test equipment that is used during protocol execution must be calibrated.
• Complete the list below for all instruments used during the execution of the protocol.
• For instruments hired for use during the qualification and therefore not in the company’s calibration system, attach a copy of the calibration certificate to this check sheet and list in the comments section.

Pre-Requisites

The pre-requisite section of the protocol should indicate very clearly, what actions or verifications must take place before the actual test protocol can be executed.

It is a common mistake for test engineers to forget to read this section of the protocol and as a result they are unable to carry out the test section correctly.

Examples:

• URS must be approved before executing this test.
• DS must be approved before executing this test.
• IQ must be approved before executing this test.
• Measurement system analysis to be completed, released and approved for all measuring equipment used to verify product features (CQAs)

Acceptance Criteria

The acceptance criteria is usually the last section before the test table starts. The acceptance criteria should clearly define what exactly must be achieved in order for the test to be successful.

Examples:

• Documentation must indicate that the instrument is calibrated pre-OQ and does not expire during the OQ testing period.
• Standard Operating Procedures exist and are available to the Responsible Individuals.
• All listed discrete inputs exist and are numbered and operate correctly.
• The results are as indicated within the test results tables.

Structuring the Test Table

Once the initial section of the text protocol is complete, the test table can then be populated with the design information required to carry out the testing.

The following fields should be considered when constructing the test protocol.

View the video above before reading the rest of the article.

Test Step Number

The test step number is required for two main reasons:

Reason 1: It allows you to add structure to the test steps.

Reason 2: It allows you to create a unique reference to the test table from your trace documents for example when using a Requirement Traceability Matrix (RTM).

Example:

• OQ-AI-001
• OQ-AI-002
• OQ-AI-003

Test Procedure

This section gives the tester the information they need to complete each row of the test table. The instructions here should be very clear and easy to understand.

The rule of thumb should be that if another tester who was not involved with the project had to execute the tests would they have sufficient information to do so.

Example:

• Log onto the home Screen, from the choose search dropdown list, choose the partID option
• Enter 189 as the Part ID number and click the search button

Expected Result

This section gives the tester the required information they need in order to verify if a test has passed or failed. The expected results should be written in such a manner that there is no ambiguity as to whether the test has passed or failed.

Examples:

• Part ID 189 should be displayed on the Part screen.
• A warning message should appears indicating that the temperature is out of range
• The IQ must be at version 4.0 and approved

Actual Result

The actual results column is the section of the protocol where the tester can input their findings from carrying out each test. There is always a debate around what needs to be inputted here in order to satisfy potential auditors.

Some test engineers like to put in a description of the test, that reflects the expected result whereas some might like to just make this a Pass/Fail column.

How you do this depends on the company’s policy towards documenting test executions, personally I think the actual result should be populated with a description of the test result and another column should be present where the tester can clearly then mark if the test has passed of failed.

Examples:

• Part ID 189 is displayed on the Part screen
• A warning message appears indicating that the temperature is out of range
• The IQ is at version 4.0 and approved

Related: Want to learn more about executing test protocols

Pass / Fail

After the actual result column, it is advisable to place a pass / fail column so the test engineer can clearly mark if a test has passed of failed.

Using this approach is also very beneficial for the quality or second reviewers, as they will clearly see what tests have either passed or failed at a glance.

Signature & Date

A signature and date column should be present in every test script regardless of the activity. This column is used to allow the tester to sign for each executed row with their own unique signature and also the date (and time if required) when the test was executed.
This signature and date provides documented evidence when the test was performed and by whom.

Point to note:

Some company’s like to get their testers to sign each row as they execute the test steps whereas other companies feel it is sufficient to sign the overall table as evidence.

Attachments & Deviations

It is also a good idea to have independent columns so you can reference attachment and deviations numbers per test row. This makes the process of understanding what attachment or deviation is associated with a particular test.

Remember to include the protocol number on each attachment and deviation document to it can be traced back to the protocol in question in the event of a mix-up.

Comments Box

Finally, it is also recommend to include a comments box at the end of each test page. This comments box can be particularly useful when extra information is required to explain certain aspects of the test execution.

Instead of an attachments and deviations column this comments box could also be used to reference them instead. Again this is something that should be discussed at the company policy level to ensure a standard approach is been adhered to.