Our testing teams are facing extensive downtime due to testing in a shared QA environment.

When our front end teams perform end to end testing, their test (QA) environment points to the back end services QA environment, which in turn points to enterprise and mainframe service QA environments.

Because these downstream QA environments are themselves constantly deployed to and tested, the result is frequent instability for front end testers. Also, the front end and service code they are testing is not being tested against the same mainframe and enterprise services that they will interface with in production.

What is the solution here? Should each teams QA environment interface with a more stable clone of what is in production? Or perhaps a UAT environment?

1 Answer 1


If you need to manually test the whole system, there needs to be a stable environment for that. It should reflect the production environment, with the only difference being the component that is about to be put live.

For example, if production has the following:

  • UI 1.0
  • Commerce 1.0
  • Tax 1.0
  • Shipping 1.0

And the plan is to launch a new version of the Tax service... you should have a stable environment to test this:

  • UI 1.0
  • Commerce 1.0
  • Tax 1.1
  • Shipping 1.0

The general idea is that it should look exactly how production will look after the deployment.

There are other ways to achieve this, but this sounds like the match for your context.

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.