views:

291

answers:

2

I am currently at a loss. We are moving from Dev-owned testing environment to a QA-owned one. I have worked in a QA-owned testing environment before. But I have never set one up from scratch. I understand that it should mirror Production as much as possible. But how? How have you setup your QA Environment?

+1  A: 

We take backups of production every week and replace what we have in QA. The production copies have all the of the sensitive information scrubbed (SSN, Email Address, Phone Number etc.) and replaced with "dummy" values.

We then use the build process to bring the refreshed QA environment up to the version of code (in UI, Business Layer, and Data Layer) we are testing.

Kevin
A: 

There are really just three requirements to setting up a QA testbed.

1) Reproducing a clean, realistic production. If your application runs on a Win2k8 server, QA needs a Win2K8 server. If you need to support 5 web browsers, QA needs all 5 installed (either simultaneously or across multiple clients). If you deploy in a client/server setup, you'll need two machines, even if your product can work with just one system. I would not overpower the typical deployment. Testing on slightly weaker hardware will help expose performance issues.

2) Consistent sample data. This could be a database dump, dummy data or randomly generated data. It should be easy to reload this time after time. If your app displays records out of a database table, you want a decent amount of sample data in there to begin with. Then the QA person can go mucking around, adding or deleting it. Include realistic data and edge case scenarios.

3) Rollback. The easiest way to handle this is with system imaging. QA needs to have a clean, untouched environment to test on, to make sure the product deploys correctly. It also allows for QA to not worry about blowing up the test environment by doing something wacky. Worst case, you just take a coffee break as the rollback proceeds.

Mike DeMaria

related questions