0

I worked as QA intern during my summer, i have a question when i used to run tests for product build. I used to find 3 QA environments associated with one Dev environment?

For instance:

Dev has 1 Environment which consisted of (Server3,Server4)

QA has 3 Environments which consisted of (Server5 Server6), (Server25,Server26) and (Server7,Server8)

Why are so many servers associated with QA environment?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
SuperMan
  • 157
  • 4

2 Answers2

3

QA might be testing multiple builds at any one time. For example, 1.0.1 (a bugfix upgrade), and 1.1 (a major feature upgrade). It greatly simplifies things to have separate hardware for each "channel".

To give you a more real world example, Chrome has three "channels": stable, beta, and developer. It's reasonable that each of these would have their own separate testing servers (if it were a program that required a server).

devicenull
  • 5,622
  • 1
  • 26
  • 31
  • Gotcha, but atleast as u said, if i say Server3 and Server4 are beta and live then it must have 2 QA servers corresponding to them right? . So is it associated to something like functional, performance and integration testing ? – SuperMan Dec 15 '10 at 04:22
  • 2
    It depends on the exact software involved. It might be that it's designed to run on two servers at once (for example a web server and database server). – devicenull Dec 15 '10 at 04:24
0

At my last shop, the dev team could be divided between normal (current gen, patches) and special projects (next gen). Special projects got their own QA environment to ease interruptions/conflicts with the current pipeline; their sprints could be stretched out. The normal group needed to support the current release plus older previous releases. So QA used two tracks and it was especially evident how necessary separate environments were when the older previous release got a patch (and the fix from the patch needed to be applied on the current release). Also keep in mind that there are potential schema changes between the older previous release versus the current release and this difference requires two separate database instances. If you start considering seed data, there is also the situation when QA is asked to reproduce an incident found in the wild at a customer site so they might import a live data sample and need to avoid interrupting testing that may already be in progress for a regular release.

杜興怡
  • 121
  • 4
  • sorry:( , i couldn't understand even a bit of it :( – SuperMan Dec 15 '10 at 02:52
  • 1
    Sorry it was a jumble. In similar terms to @devicenull, our normal team could be split between 1.01 (patch) and 1.1 (current release) testing. The special projects developers would be working on 2.0 (next gen). Schema changes could be introduced in 1.1 for a new feature which would require a separate database from 1.01. Finally, to provide engineering support (escalated out of customer service) for issues reported from the field, often times a QA environment was prepared with live sample data; this environment needed to be separate from normal QA testing. – 杜興怡 Dec 15 '10 at 17:10