This might be not technical but rather process driven query. Help me redirect to right forum if this is not the place to ask such question.

Typically in a project, we have a deployment environment where development team deploy the code for testing purpose. Testing team executes test cases on the environment.

But I have seen projects where there are multiple environments for different teams to test on, and when I get to understand that what's the point? I do not see any reason than to have multiple environments.

Two environments:

1. Lower Environment- Developers can use this environment to test their code( this environment will be an exact replica of higher environment where Internal and External testing will happen). We use SVN and checkin the code.

2. Higher Environment - where multiple testing team can test which from my experience seems stable env. to test on.

But we have lot of environments....and time to time support has to give on different environment.

But I see multiple environment where testing happens with no apparent concrete reason. My question is who's responsibility to support multiple environments? I find it difficult for development team to work on supporting multiple environments apart from regular dev activities, Unit test case preparation, get clarification from the design or business on User story.

Any suggestions would be highly appreciated.

  • 1
    please don't cross-post: stackoverflow.com/questions/32602008/…
    – gnat
    Commented Sep 16, 2015 at 14:11
  • 1
    I have asked SO user if this is the right forum; I have been redirected to this forum that why posted this question here. I don't think it counts for downvote.
    – Akki619
    Commented Sep 16, 2015 at 14:24
  • Please flag your question and ask to migrate it in such cases.
    – superM
    Commented Sep 17, 2015 at 7:31

2 Answers 2


In modern development, team should be responsible for project analysis, design (architects may align flawed design), development, unit testing, automated QA/UAT/PERF testing, deploying it into all envs, operating and monitoring in production till the project is decommissioned from PROD or not used by customers.

Modern development practices involves automation of everything into single build, test, deploy pipeline.

The idea is to provide to the team platform with self-services, so that team can achieve all above tasks with smallest possible outside interaction. Any ticketing system is burden that should be changed to self-service.

So in such environment would have cross-functional team members (YES sometimes developers writing non-unit tests and be woken up in the night if the application is down). Idea is to have on team experts on each area of development process and mentor members of the team not familiar with certain skills. So you can end up that tester or operations engineer will be mentoring you.

You are lucky if you are already working in such company, but if it is not at least investing and trying to convert itself towards full automation Continouous Delivery/Deployment, it's time for you to change the company!


Several examples I came across:

  1. The production and test/dev environments have different set of features. As an example, a project I worked on included scheduled updates of state. In the production environment, the updates were scheduled once a week, but in development and testing environments, we needed the state to change more frequently or be triggered manually. So we had a kill-switch for manually changing the state.
  2. Avoiding conflicts between the tests run by different teams. When looking for defects, being able to reproduce the defects is extremely important. Having multiple teams working on the same environment can make this difficult, as the steps revealing the defect might be the result of the actions of multiple teams (accidental) crossing. JUnit, the famous unit testing framework, creates separate objects for each of the test cases. This is done so that every test case is isolated and doesn't affect other test cases. The same principle applies here. Instead of coordinating the testing plans of multiple teams, each team works on a different environment.
  3. Different platforms, hosting the product. If the product supports multiple platforms, it should be tested on each of them. Moreover, it should be tested on each version of each supported platform (Windows XP, Windows 7, Windows 8, etc.). Each requires separate environment. The upgrade scenarios both of the product and the platform increase the number of necessary environments as well.
  4. Stress-testing, stability testing. Some tests require that the product is under high workload. Others test the stability, so that the environment has to be up for a large period of time. These types of tests require dedicated environments.
  5. Conflicting settings. For example, the team testing the localization has to change the language of the environment multiple times. This can cause inconvenience for others teams, which aren't familiar with all of the supported languages.

In my experience, the QA team is responsible for creating and maintaining the environments. But to do this properly, the QA team needs to have a clear list of the points above, including the supported deployment types, platforms, settings and features to be able to create a proper test plan.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.