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.
–
user246Aug 2 '11 at 13:18

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 '11 at 19:40

Now THAT seems to be a much better worded question and one worthy of sqa.stackexchange
–
TristaanOgreAug 2 '11 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.
–
user246Aug 3 '11 at 3:01

3 Answers
3

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 )

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.

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 '11 at 19:30

How those environments differ in configuration? What makes them D, T, A or P?
–
dzieciouSep 15 '13 at 19:31

(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"