Why We Need Separate Development, Testing And Staging Environments

Why would anyone need separate development, testing and staging environments? A testing environment is a protective space that helps programmers avoid errors and meet deadlines by isolating components of their program from the rest of the software. It is often built out of steam tunnels or set up in an office or lab.

Testing environments help to mitigate potential risks, such as bugs and security vulnerabilities, and save time and money because it’s easier to catch mistakes quickly (e.g., through automated tests) than it would be otherwise. A testing environment might be protected by firewalls, include controlled network access, have segregated power, limit physical access into secure areas, provide controlled network monitoring/logging capabilities/etc., etc.

Historically, testing environments were often located in buildings that were separate from regular office buildings. This arrangement, where the test environment was in a separate building (or even an entire floor in one building), allowed developers to run simulations of their systems without interrupting regular workflow. For instance, if the system was prone to lockups when there were too many users accessing it at once, these tests would fail in the testing environment and developers could track down the bug before it made its way onto production systems.

Or if a new piece of software’s code worked correctly when it was tested with 1 user but had problems under heavy loads, it would be possible to isolate the code from other processes on the network and run tests to get more data about what was happening.

In addition to this, developers run tests in live environments in order to make sure new updates and fixes do not affect normal use of the system.

Common types of testing environments

1.) QA environment

A QA Environment (QAE) is a testing environment that is used to test the software. This includes testing the code and also performance and stability testing. The QA team mostly needs a separate environment from the development environment since the development environment is always changing and will affect the testing environment. It is recommended to separate the production environment from the QA and Test environments by using a user authentication system. This separation allows for complete isolation of data and different users can be given access to each environment.

2.) Development environment

A Development Environment (DEV) is a testing environment that is used during the software development process. The Dev environment consists of the Programming language, Operating System and all other tools necessary to develop and maintain the program. The Dev Environment can be part of a QAE or stand alone but it must be consistent with the QAE in order for both environments to share information such as defects, logs etc.

3.) Staging Environment

A Staging Environment (STAGE) is a testing environment that is used for testing. This environment is used to ensure that the program or software can be successfully deployed into production. A feature may not be feature-complete at the time of its completion, but it must still pass verification tests before it can be included in the deployment process.

Often the staging environment will not have all of the services that are available in production. This can be done with blue/black/grey separation of environments or by making very sure that all applications being tested have been manually disabled or removed from the production environment. It is often recommended that the staging environment is configured as closely as possible to the actual production environment.

4.) Production environment

A Production Environment (PROD) is the environment that the software product will be deployed to. The Prod environment should be identical to the stage environment except for minor test adjustments. Minor changes might include removing some security settings before it is released, but often the Stage environment has all of the features that exist in production.

So, what’s the need for separate development, testing and staging environments

• Quick testing and easier to catch bugs – this is due to the fact that each team works independently using their own resources without ay overlap or influence from dev environment
• Reduce corrupting production data by mixing it with test data – Dedicated testing environments provide a place to explore without worrying about live data.
• Keep the system secure – only specific system administrators get read/write access to production data.
• To allow for flexible testing – A development or QA environment can allow the testers to clean the data whenever required, providing flexibility – this cannot be done on production environment

General testing flow through the environments

Step I

• Developers write code and deploy changes to the development environment. They test that the changes work as expected.

Step II

• The application is moved to the QA environment. It is set up with all required development tools and the code is tested, by running tests in this environment. The developers are still in production(Dev), but not performing any changes to it. This way they can still use the same database/computer configuration file if required for their test scenario. The QA team do the manual tests and confirm test cases are passing as per requirements.

Step III

• If everything goes well, the changes are deployed to the STAGE environment. Automation tests are ran, and if the automated test suite pass, then the final step is application deployment to the production environment. Step IV – Application Deployment

Are all the environments necessary?

In most companies that have sizeable teams that have defined roles, yes – This is necessary. However, in very small teams where most tasks overlap – it would not make the most sense to have all those environments if they are not used as they should be. Some smaller companies often have two environments – testing and production. It is upon the company to choose which setup works best for them.

Conclusion

The idea behind this type of software testing is that a program or application will remain in one environment until it has been completely tested. The entire system will be tested in a single environment and if anomalies are found, the program/application can be fixed and tested again in a single environment. It is only once the program is completely stable that it moves to the next state or stage.