Smartlogic

ולידציה – GAMP – Test Environments – Test Data Sets

ולידציה  Good Automated Manufacturing Practice – GAMP – Test Environments – Test Data Sets

Test data sets are often use where the test environment does no permit the use of real data for reasons of availability or confidentiality, or where the real data are not generic enough to cover certain test types (e.g., challenge testing at boundary conditions or stress testing).

                          Representative Test Environment

Test data should represent as close as possible the actual data to be operated on, in terms of volume and range of possible values (including invalid entries, to check that they can be correctly handled).

Differences between the proposed test data and the expected actual data should be detailed on the Test Specification or Protocol, and subject to impact assessment. If necessary, additional tests should be planned for the production environment in order to cover identified risk scenarios.

                         Control of Test Environment

Test data sets should be placed under configuration management and the version in use recorded.

For automatically generated data it may also be appropriate to control the utility used for generating the data, as well as the test data set

                         Removal from Production Environment

If the test data SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

If the production environment includes automatic audit trailing, then it should be recognized that all audit trail entries from the testing process will remain.

                              Test User Accounts

Test user accounts are often used to permit testers to access the system at different levels, and ensure that activities carried out during testing are easily identified within any resulting audit trail.

                          Representative Test Environment

Where test user accounts are often used, these should be set up to represent each group of users within the system, including the corresponding authorizations. For multi-lingual system, test user accounts using foreign character sets should be included. Similarly, if existing individual accounts are used for testing, representatives from each group should be included.

                         Control of Test Environment

If test user accounts are used, then the setup of the accounts should be retained as part of the test documentation. Where there are issues of data confidentiality, controls should be exercised to ensure that the use of test accounts does not cause breaches of confidentiality.

                        Removal from Production Environment

If the test user accounts are added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

                            Test Documentation

The test environment includes documentation used during testing. This should always include the test documentation (Test Plans and Strategies, Protocols and Test Specifications, Test Cases and Test Scripts) and the controlling Design Specifications. It may also include operating procedures such as SOPs.

The test documentation should be controlled and recorded to a level of detail that would allow it to be retrieved as part of later review of the test results. This control would, at minimum, include the recording of current document version levels.

ולידציה – Introduction to GAMP Test Environments

ולידציה – Introduction to Good Automated Manufacturing Practice (GAMP) Test Environments

The environment in which testing is conducted should be determined based on the life cycle output of the risk assessment. The following general principles apply:

  • The proposed test environment should represent as close as possible the production environment. The differences between the two should be detailed in the Test Specification or Protocol, and should be subject to impact assessment.
  • The test environment should be controlled and recorded to a level of detail that would allow it to be reconstructed if necessary. Such control includes:
  • System hardware (HW) and software (SW) components
  • Test HW (versions, serial numbers, as appropriate)
  • Test SW (version control of any simulations)
  • Test data (version control of any test data sets, test recipes, etc.)
  • Test user accounts
  • Where test HW/SW/data/user accounts are applied as they may appear in the production environment, controls should be available to ensure that they can either be removed cleanly or isolated from use (either logically or in time).
  • Where the test environment is required to undergo a temporary change to facilitate the execution of specific tests, both the change and its removal must be formally documented.

 GAMP Test Environments

In many circumstances it is undesirable to conduct all testing on the final production environment. Common examples include:

  • Non-availability of infrastructure at the point in the project life cycle when testing is carried out.
  • Non-availability of certain interfaces.
  • Requirement to test changes outside of the production environment prior to installation.
  • Requirement to carry out tests which may be destructive to the production environment.

 

The progression of SW build from a development environment through production environment depends on the risk priority associated with the system being installed or the change being made, and on factors such as the ease of possible modification removal from the system.

A change to a custom data processing module in a large business system may require progression from a development environment to a test environment, to a validation environment, and then to the production environment. This may be required because the change is a high risk priority, and, even if the if the original module could be restored easily, the test data may remain in the production environment.

Some tests, e.g., Performance Qualification (PQ), or part of it, may need to be conducted in the production environment.