Why should QA have their own QA Environment? What are the pros and cons?

Question

Versus using the DEV environment for testing even though it has the latest code

I want to know what are the pros and con if QA have their own Test enviornment. How should it work? Who should make deployment to it? Should it have the latest code? How does it benefit QA or developers or does it benefit anyone?

Answer 1

I don't see any disadvantages to having separate environments. Ideally, wouldn't every individual have one or more environments of their own to use as they see fit? Why would you restrict both groups by making them share one environment?

Answer 2

Giving them their own environment means they can avoid the it works on my machine issues. They can do a clean install and it will fail if they don't have a dll or other requirement which may be available on a developers box. now a days their are few reasons not to do this if only through virtualization. As your question points out they and your customers are not likely to be running the bleeding edge of your development tree. but a tagged release that is several revisions behind development.

Answer 3

The fundamental principle behind QA testing is that the QA person should have no preconceived notions about what you did in the code.

If programmers were objective about their own code, you wouldn't need a separate QA department.

A separate environment also allows QA to test installation issues and fulfillment of all software requirements.

Answer 4

You usually setup a separate QA environment, because you want to give the testers an isolated environment on which to test, so that developers and testers can work at the same time.

The DEV environment is typically volatile, which makes it very difficult for QA to get through an entire test cycle, especially regression testing. If the QA department tries to run a full regression test on a system that is constantly changing, it would be impossible for them to reliably state that all features are "working" at any given time.

Answer 5

A few thoughts come to mind:

1. If QA is using a dev environment, that environment is likely changing. It is hard to control the state of the environment with multiple people working against it.
2. Typically, QA environments mimic more closely production environments than do development environments. This helps ensure functionality is valid in an environment that is more production-like.
3. Developers tend to have lots of tools and things running in their environment that could affect QA validation.

Answer 6

DEV is where developers bring their code together. It is likely that DEV is in a constant state of flux. Whereas QA should be slightly more stable. This way QA is less likely to encounter code that isn't ready and developers can bring their code together to test before QA gets their hands on it.

Answer 7

For us we do scheduled releases to the "QA" environment while we continue to develop in our development environment. This way we there is no overlap, and they are simulating an actual user environment.

Answer 8

Besides the other things already mentioned in this thead, one very important aspect is that you can test the deployment of the code by having a separate testing environment. For example, if there's an important configuration change (such as a required system library update or new database table), you need to test this before moving the code to the production environment.

My deploying the code from dev to testing, you can automatically test if all dependencies / configuration changes are taken care of. It is important to keep the testing environment as close to the production environment as possible for this.