There are numerous of different testing environments that I have come across with, and ALL of them seem pretty useful and helpful but which ones are necessary.

For example ... I have seen:

  • Development
  • QA == Functional testing of the system
  • System Integration Testing == Tests the system from end to end
  • User Acceptance Testing = Allows the user to validate the functionality over time
  • Production == Production
  • Production Parallel == A parallel of production to replicate production issues
  • CCE = Client Certification Environment

With a lot of different type of testing that could happen (http://www.guru99.com/types-of-software-testing.html).

What are the most common set of environments and best practices for each environment?

  • 2
    Can you be more specific? There are many imaginable test environments. Each of us could recite our test environments, but what is right for you depends on your circumstances, not ours. One size does not fit all.
    – user246
    Aug 2, 2011 at 13:18
  • 1
    This seems to be taken straight from a list of common interview questions. allinterview.com/showanswers/3735.html Aug 2, 2011 at 16:10
  • Indeed, I agree with user246. Provide some background as to why you're asking the question. One of the hallmarks of a good question is evidence of self research, which this question is most definitely lacking.
    – corsiKa
    Aug 2, 2011 at 19:40
  • Now THAT seems to be a much better worded question and one worthy of sqa.stackexchange Aug 2, 2011 at 20:09
  • 1
    You asked a good question, and we are glad you are curious about test environments. However, entire books have been written about smaller subjects. By way of analogy, one might ask, "What are the most common programming environments and what are the best practices for each?" or "What are the most common ways to deploy software and what are the best practices for each?" Instead, perhaps you could describe your own project and ask a specific question about its test environments.
    – user246
    Aug 3, 2011 at 3:01

4 Answers 4


I am not sure what you meant by "role" here and some elaboration would help in identifying what exactly you are looking for. Nonetheless, we usually have have the DTAP enviroments for our sprint/release cycle:

  • D - Dev (here you can pair with devs and help write junits and do dev-box testing before commits.)
  • T - Test (the test environment where the automated regression suit runs after each commit/on-demand/periodically. Major chunck of the exploratory/story/functional and non-functional testing is done on this environment since its independent of the dev env it mostly take care of all dependencies of interfacing with external services/clients to enable system level testing)
  • A - Acceptance (Product Owner does the acceptance testing after deploy to this env in between or after a successful sprint.)
  • P - Production (Finally a release is deployed to prod 'sprint-ly' or as per release cycle. Smoke tests are run after deploy and accessibility checks are performed periodically)

Depending on the criticality and the type of your application you might have a few variantions like a staging environment(mostly when you have to migrate/test on real prdocution data), pre-production (where you can test user profiles,security, disaster recovery and back-up) and production environments.

  • 1
    I have seen many places who separate out the smoke tests into a new environment called "Staging" - it makes an environment as close to a copy of production as realistically possible and you run your tests here. Ironically at my present firm, we use two production systems as staging on the bi-weekly-Tuesday before we send it to all the production systems on bi-weekly-Thursday.
    – corsiKa
    Aug 2, 2011 at 19:30
  • How those environments differ in configuration? What makes them D, T, A or P?
    – dzieciou
    Sep 15, 2013 at 19:31

At the risk of flogging a dead horse, this is one of those context-free questions that is tough to answer without information specific to your needs.

I won't rehash what people have described about commonly used environments, but I would like to offer a few things to consider.

As with most things, there are no best practices, there is what is appropriate for the situation you find yourself in. I've worked in companies where you could rapidly clone an entire environment and have as many running as your hardware had the capacity to support. I've worked in other places where the environment was so ponderously large that mimicking the entire thing 1:1 would have been ridiculously expensive. I've seen places with very relaxed development processes and others where things were very rigid and strictly controlled. How we worked within each of those constraints (or sometimes outside of them) differed from one to another.

Here are some things that might affect what environment(s) you have and what you use them for.

  • What sort of development style are you using? Are you working in a waterfall environment? an agile one? somewhere in between?
  • What kind of testing are you looking to do?
  • How do you update your environment? Do you get builds delivered to you? Do you pull code from the repository?
  • Are your environments small and self-contained or large and complex?
  • Are you using individual data sources or do multiple environments share a single db? (I've seen both)
  • Do developers and testers work very closely together or are they separated (by time, distance, culture...)
  • Do you mock up any part of your environment? Does that change over time?
  • How do you release software to production?

and so on

Answer some of these questions, then see what questions you have about different environments (you know, unless you really were looking for a pat answer to an interview question :P )


1 What are the most common set of environments and [2] best practices for each environment?

(1) System Test, UAT, Performance Test, Staging are all classical environments

(2) Best Practices is a harder one :-) .. Here is a cool Test Environment Maturity Model TEMMI .. Other than that my advice is this ... "Understand your environments .. Without knowledge the service and capability will always be deficient"


Development, SIT (System Integration Testing), Performance Engineering Environment, Production, IOT (Interoperability Testing), DR (Disaster Risk) , UAT (User Acceptance Testing)

  • 1
    The question itself has better description then this answer! Apr 10, 2016 at 5:05
  • Please add more description for each type of environment. As it stands, your answer is of little value.
    – Kate Paulk
    Apr 11, 2016 at 12:18

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