A testing environment is an environment where you can test any change or bug fix before forwarding it into your release. It is considered a best practice to have multiple testing environments. Even a Dev environment is a testing environment, which is more like a whiteboard for developers to make a change and perform unit testing onto the code.
A Staging environment is also a testing environment but is dedicated to QA or software testers. Some would say “it is a copy of production”.”An environment similar to prod but without any customer.” I define it as a mirror environment meant to mimic production as precisely as possible for quality assurance. I consider it to be a Goalkeeper, standing tall as the last line of defence between the bugs brought in by the recent release process and the production environment.
And before you ask, Yes, staging environment should have a complete simulated copy of databases as well.
If you have used XAMPP than it also creates a testing environment by hosting your website on Apache web server.
To have a detailed understanding, have a look at best practices for Software Testing.
Most of the times a web-app workflow comprises of 3 environments dedicating one for each team: Dev, QA a.k.a Staging & Prod in your release workflow.
Developers are free to apply fix on existing bugs in any way they deem efficient in the local Dev environment.
Developers perform unit testing for the validation of the latest feature implemented by them.
Once unit testing is successful, the feature is pipelined into Staging or QA for testing and quality assurance.
Staging is where regression testing takes place to make sure that recent features are applying a fix to the problems without disturbing any other functionality of the existing application.
Release date arrives and the features who passed with flying colours in the Staging environment are migrated to Production.
Now that we have a good understanding of the workflow. It is time to deep-dive on best practices.
DEV LOCAL Environment – DEV environment allows developers to make code changes into the application for fixing an existing bug. Once the fix is applied it is unit tested by the developer. We already know by now that testers are not advised to perform testing in DEV.
Integration Testing Environment – When different bug fixes related to different modules are done with successful unit testing then integration testing is performed. This environment is where all different modules are integrated and hit with a plethora of test cases to bring the code up to speed after integration.
SANDBOX – They say “Necessity is the mother of innovation”. This playground for developers is where innovation rises in form of code to meet the necessity. This is of no use to a tester.
STAGING Environment – By far I hope you are pretty aware of what it does. A pre-prod deployment area that serves a quality assurance check by providing a platform almost identical to Production. Sometimes when we are in a hurry to deploy immediate fixes, we tend to miss them out on this environment after integration testing. This is not a good practice. Make sure you migrate everything and test into Staging to be safe. Remember, staging is the closest twin to prod.
PARTIAL PRODUCTION ROLLOUT – Develop a rollout plan for thorough testing in Production, including the following mentioned major areas related to code migration:
- Distributed Tracing
- Dynamic Instrumentation
- Feature Flagging
- Exception Tracking
- Traffic Shaping
- A/B Testing
- Chaos Testing
- Load Testing
- Load Testing
- Usability Testing
- Cross Browser Testing
- Accessibility Testing
Production – After validation in the QA environment, you push your changes to Prod. Go-live environment that is used by your customers. This environment is not to be messed with! Developers without proper approvals cannot implement any change in it, not even a minor fix is advised without a relevant sign-off.
Disaster Recovery – This is where you keep a backup ready of your Production before making any change into it. If things go south you can execute a rollback to the previous version in a fly.
But you can’t always roll back! For instance, If you are coming up with a release that brings with it a new database structure which is conflicts with your previous release associated database then rolling back would be catastrophic and may even shatter your application.
Hope this clarifies your ambiguity on the difference between a testing and a staging environment. Long story short, there are plenty of testing environments in a release cycle but there will be only one Staging environment. Every Staging environment is a testing environment, however, vice-versa is not true.