Validation of ERP/CRM Software Using Sandbox

[Kymmie]

Hi all!

We are currently in the process of writing test scripts to validate our ERP/CRM software. My question to you is this - Do you think we need to run the tests in our active production account, or is it acceptable to run them in our sandbox account? My concern in running them in our production account is that if someting DOES go wrong I do not want to cause any problems in production. We are currently using the production account for non-GMP related functions, and are also using it for GMP-related functions although we are doubling those up with redundant (hard copy) methods as well (the reason we are doing both is so that we can build some history into the system before we go live with it). Thank you in advance for any advice/suggestions you have.

~Kymmie

 

[BethP]

Prior to running any scripts in Production environment, I would recommend first running them in your Sandbox (Test) environment and monitoring the results there. If your Sandbox does not match Production, with exception of known code changes to be moved to Production, you may want to work with your development group to get a code / data refresh of your Test Environment.

When I've worked with an ERP system, we had a few accounts in Production that were clearly indicated as TEST to utilize for smoke testing when changes were moved to Production. Accounting knew of these accounts, and worked with us to cancel any transactions that would impact the GL. The bulk of testing occurred in the Test environment, and only after we were satisfied with performance in that environment were changes promoted. It can get very messy to utilize a Production environment for testing.

NOTE: when moving to a new system, it may be useful to do parallel processing as you described in old / new system as well as data migrations. Again, these are normally done only after test environment is stable and are part of your production roll-out plan. These transactions generally would not need to be backed out of Production.

 

[Kymmie]

BethP,

Thank you for your comments. I think I need to rephrase my question a little better. What we are trying to figure out is... Is testing done in the sandbox account sufficient to please the FDA, or will they want to see us test in the production account as well? If testing in the sandbox IS sufficient, then is there any documentation we need to prove that the sandbox account is a replicate of the production account?

Thank you again for your time,
~Kymmie

 

[yodon]

We generally state in the Validation Plan that a sandbox database will be used to isolate test data from production data. It doesn't hurt to indicate why that's considered "production equivalent." The test report can / should define the test environment and you can (further) establish equivalence there. The "before it happens" approach is typically more acceptable than the "oh yeah, this is what we did" approach.

 

[Mr. Marc]

You are leaving out some key information for this decision, but the defense position is that you can demonstate the non-production environment (i.e., including hardware and software controls) used as the basis for validation is functionally identical to the production environment. Since you cannot often validate directly in production, you need a "psuedo". Sandbox is often not a formally established and controlled environment. This formality includes change control on the release under validation (i.e., validation will formally challenge the delivered and tested product from IT engineering, once the release is frozen and place under change management). Their should be no more work planned for this particular release, when it is delivered to validation.