Answers: <p>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.</p>
  <p>For example, if production has the following:</p>
  <ul>
  <li>UI 1.0</li>
  <li>Commerce 1.0</li>
  <li>Tax 1.0</li>
  <li>Shipping 1.0</li>
  </ul>
  <p>And the plan is to launch a new version of the Tax service... you should have a stable environment to test this:</p>
  <ul>
  <li>UI 1.0</li>
  <li>Commerce 1.0</li>
  <li>Tax <strong>1.1</strong></li>
  <li>Shipping 1.0</li>
  </ul>
  <p>The general idea is that it should look exactly how production will look after the deployment.</p>
  <p>There are other ways to achieve this, but this sounds like the match for your context.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-08-18T07:42:07.530Z
Answers: 2023-08-18T07:42:07.530Z
Answers: Fenton
Body: <p>Our testing teams are facing extensive downtime due to testing in a shared QA environment.</p>
  <p>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.</p>
  <p>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.</p>
  <p>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?</p>
  
Tags: <jenkins><continuous-integration><testing><software-engineering><mainframe>
Title: QA instability due to lack of stable UAT/staging environment
UserDisplayName: Half_Duplex
ThreadText: # QA instability due to lack of stable UAT/staging environment
  
  (Asked by: username_0 on 2023-08-17)
  
  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?
  
  **Tags:** jenkins, continuous-integration, testing, software-engineering, mainframe
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-08-18. Score: 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.
  
  
  ---
  
  