Originally published May 23, 2019, updated May 3, 2022
Software Development Lifecycle (SDLC) involves multiple activities, such as planning, analysis, design and development, different types of testing, deployment, and maintenance. These activities usually happen in different software environments, which could be classified as development, testing, staging, and production environments.
Confusion sometimes arises when differentiating between testing and staging environments. Both are used for testing but at different times during the project. This article aims to clarify the testing vs. staging environment puzzlement for business people and those who are new to the subject.
Defining Software Environments
What is a development environment?
Developers configure development environments so that they can write code and test it before making it live. Generally, the development environment is smaller than the actual production environment and does not exactly match the real-world scenario. It also comes with developer-specific tools and has undergone rigorous QA validation.
Another thing that makes it stand out is that its source code constantly evolves with new functionality. This might make the work of developers, QA engineers, and software testing teams harder. This is where the testing environment comes in.
What is a testing environment?
The testing environment (also known as the QA environment) is specifically created for functionality and system testing purposes. Test environments test individual parts of an application and require a different setup for all code parts.
A testing environment is where QA engineers perform different types of testing, including:
- functional testing
- eCommerce integration testing
- performance testing
- load testing
The test environment always includes the eCommerce software to be tested, test data and test environment management tools, the operating system, database, desktop, or mobile device(s) on which the software is to be tested.
Test environments have many benefits, such as:
- getting rid of the bugs
- providing feedback about the behavior and quality of the application under test
- encouraging improvement and innovation
- effectively tracking a new product or update progress to ensure the user has the best experience possible
What is a staging environment?
So, how to define the staging environment, and where does it come in? Basically, it is an environment where user-acceptance testing (UAT) and interface testing are critical.
Here, the replica of the main site or app is created, and changes are made according to the requirement.
It’s the last step in the software development process before deploying changes to your live website. Staging lets you extensively test any code changes your dev team made to ensure they work as intended. So, if your eCommerce site requires some changes, it will be pushed to the staging environment.
Staging environments have the same configuration, architecture, and scale as production environments. So, a staging environment is essentially the sweet spot before you know that your production environment is successful.
Why do you need different software environments?
Even though development and testing typically happen simultaneously, you will eventually need to freeze your work and deliver the results to the customer or roll out your final product. This process is called deployment and it usually happens in frequent intervals so that your delivered product becomes MVP-grade (minimum viable product) as soon as possible.
Now, before you can deploy your code from your development environment into the customer’s production or deployment environment, there are a few more things for you to do. The first one is testing. To ensure the testing is properly set up, there’s a need for a separate testing environment. It is specifically configured to allow QA specialists to effectively execute automated testing and check the system components and major functionalities in different use case scenarios.
The second activity you usually need to do before placing your code in production is the user-acceptance testing. This is when you check the entire system in the exact way it is going to be used in production, including live data volumes and types of data as well as user behavior. This type of testing requires a staging environment, which is identical to your production environment except that it’s not publicly accessible to end-users.
Let’s consider the main differences between these environments and why you may need them all during eCommerce implementation.
Development Environment vs. Testing Environment
A development environment is configured to enable developers to write code quickly, verify it by creating basic tests (unit tests), and be productive.
This local environment is much smaller than what it takes to run an entire application in real-life eCommerce and marketplace implementation. It also features developer-specific tools that may at times hinder rigorous QA validation. And most importantly, the development environment is constantly changing – with new functionality being added all the time – which makes it difficult for QA engineers to run time-consuming tests, e.g., regression or integration tests, without disrupting the development process.
A testing environment is where QA engineers can use a variety of testing tools to run all their different tests over the application code taken from the development environment. While developers check their code for simple bugs before passing it for quality assurance, QA engineers execute more complex and time-consuming tests to check the compatibility of the new and old code, the correct integration of different modules, the system’s performance, etc. Running such tests on the development environment would lead to a huge waste of the developers’ time.
Testing vs. Staging Environment
Even though testing is typically performed alongside development, the need for user-acceptance testing in a staging environment is of paramount importance.
A staging environment is an identical replica of the customer’s production environment, which also typically contains real production data that’s been sanitized for safety purposes. It is hosted in the same way as the production servers and involves an identical setup and update operations. Therefore, testing in a staging environment offers the most reliable way to check code quality and ensure the production servers are successful.
A testing environment – even though critical for ongoing code quality assurance – can hardly achieve the same real-life degree of the customer’s system emulation.
That’s why it is a common best practice to have the application code fully tested on the staging environment before moving it to production. It is considered a must for enterprise applications.
Do You Really Need a Staging Environment?
Everyone who runs a website that generates income and has sizable operations needs a staging test site. Below, we list some critical benefits of a staging environment.
Firstly, you can take your time. Imagine a change on your site involves updating several templates – if you change one but not the other, that could break the site, especially when updating the templates one by one. So in the minutes between update to template 1, and to template 2 – the site could not work correctly and maybe even stop your eCommerce. But if it’s not live, you can have enough time to make changes and check if they work as intended, thus preventing critical bugs to the site.
A staging environment can also be helpful for beta testing and when presenting a final version of a product to give feedback and make any changes before a website launch, for example. Having the opportunity for feedback at various points of the process helps make the entire flow more streamlined and less costly.
However, there are some drawbacks to be aware of:
- Updating your website takes longer (as you need to test changes first).
- There are additional charges for a staging site service (although you can always set one up locally).
- Staging sites may not always mirror a live website (caching is not usually enabled on a staging site, for example).
Testing and Staging Environments in OroCommerce
Not all OroCommerce Enterprise Edition licenses come with a staging and testing environment, so ask your Oro Representative if this is a requirement.
However, customers can always add development and testing environments to their OroCloud environment for an additional cost. The OroCommerce staging and testing environments feature advanced monitoring, backups, redundancy, and other DevOps capabilities necessary to ensure rigorous UAT testing for a custom-tailored OroCommerce implementation.
Frequently Asked Questions
What’s the difference between a staging environment vs. QA environment?
The staging environment is where multiple developers work and test individual units or components of the software. QA environment is where the build is deployed so that QA engineers can test the existing functionality, log the bugs and retest the fixed bugs, and perform code reviews.
How many test environments do I need for an eCommerce website?
There isn’t a one-size-fits-all answer. In the enterprise marketplace and eCommerce software development life cycle, the bare minimum is four:
- Development environment – Developers should constantly test the code they write.
- Continuous Integration (CI) environment – the CI server will take care of testing the whole unit after each iteration push.
- QA environment – this is where end-to-end tests are run, manually, automatically, or both.
- Production environment – Testing in production (e.g., A/B testing) is essential for businesses that need to learn about their UX when using their software.
What are some staging environment best practices?
- Continuous delivery and deployment: getting quick feedback on changes allows you to focus on how those changes affect your environments. This is critical for recovering from unforeseen production issues.
- Use the same tools for logging, measuring, and monitoring as in production to properly maintain the staging environment
- Test as often as you can: push your code to staging at the end of every sprint or iteration (this may involve pushing it every day, every other day, or every week, depending on each sprint).