This content is part of the Essential Guide: Don't panic! The definitive guide to IT troubleshooting
Manage Learn to apply best practices and optimize your operations.

A good QA team needs a proper software staging environment for testing

Testing on an accurate staging environment is essential to the QA team's ability to accurately determine how applications will perform in production.

As a test team, we generally do the best we can with what we have, and what we have never exactly matches production....

What we test on and how the software is configured does not match -- cannot match -- every configuration possibility a customer encounters. What a staging environment provides is an exact replica of production for testing efforts. The hardware, servers, platforms, databases, database triggers and anything else match exactly to your production environment.

Amy ReichertAmy Reichert

It goes without saying that neither a company, nor a test team, nor any development organization can guarantee their software is defect-free. I can guarantee you that there is never enough time to cover all test scenarios to ensure code is defect-free, whether using automated or manual test efforts. Therefore, as testers, we have to use risk analysis to determine what areas are more problematic and require more focused testing. Validating that risk analysis requires information about the way the application runs in the actual production environment.

What is a staging environment?

A stage or staging environment is an environment for testing that exactly resembles the production environment. In other words, it's a complete but independent copy of the production environment, including the database. Staging provides a true basis for QA testing because it precisely reproduces what is in production. A well-implemented staging environment makes it possible to define the important standards and test those accurately.

Now, consider a test team that executes all of their tests in a nonproduction environment. For example, in most software development organizations, there are multiple environments for development coding and QA testing on the way to a production release. However, neither the development nor the QA test environment has exactly what the production environment does.

The database is usually not the same -- close perhaps, but not the same. The configurations and platforms may be different. The back-end third-party systems used may differ due to the cost of licensing or installation restrictions. The bottom line is that what they're testing is not exactly the production code because they're testing on nonproduction environment with simulated data. They face the distinct possibility of releasing critical defects to customers because they're not testing in a real-world environment.

Developers and QA pros tweak these environments as needed to simulate testing on production, but simulate does not mean create the same thing. The test team won't see the issues when the environment is not the same because the playing field, so to speak, is not even. Sounds like a place for test escapes and defects to thrive and grow. Maybe there's a better way.

Why is a staging environment critical?

Testing on a staging environment provides a more accurate measure of performance capacity and functional correctness. As Web applications become more mission-critical for customers, it becomes increasingly important to test on environments that exactly mimic production because it's production where customers use your application. Any defect found in production is a miss or an escape. Any defects experienced by customers in production negatively impacts your application's and company's reputation.

More on software testing environments

Learn what software testing challenges to look out for when building and maintaining a staging environment

What is the biggest pitfall in cloud database testing?

In the current business climate, as new applications become more widely available in health care, government infrastructure and financial transactions, it's become more critical that your application doesn't fail. It's critical to not offend, disappoint or annoy your customer base, because with so many products and producers, it's much easier for costumers-- even internal customers -- to switch.

Customers prefer not to be surprised. No one wants their system to go down or to go really, really, really slowly. As workers, we don't want to be negatively impacted at all by software upgrades. As working professionals, we want software upgrades to be seamless, unnoticeable -- a non-event. The only way to truly ensure that your software doesn't interrupt or interfere with your professional users is to test on a staging environment.

As a company, it's tempting to bypass creating a staging environment for preproduction testing. However, when producing mission-critical software of any kind, the staging environment is imperative to ongoing success.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

You are so right - we do the best that we can with what we have. In my case, what we have is a complete lack of a staging environment for most of our testing. This bit us just in the last couple of weeks, when our software worked in QA where a Microsoft update had been applied, but it did not work in production, where the update was not schedule to roll out for a couple more weeks. Our problem is that we're having trouble getting resources dedicated to creating/maintaining a staging environment. We all know we need one, though.
I've never actually been able to get an environment that exactly replicates production. This can be difficult because of the server config (yes, even with virtual environments), special data that customers use, and the scale/load the environment is used at. With mobile products, sometimes there are just too many variations to exactly replicate what a customer will use. 

Trying to get a few environments that approximate a few different customers might be a better goal for some. 
I'd say it's a useful heuristic.
Yes, if you replicate pretty well the environment you have one problem less to worry about. So you can worry about usage patterns more. At the same time, using risk-based performance testing approach you can identify such issues like concurrency and race conditions without simulating usage patterns and replicating production.
Example. Run a test gradually simulating 2 users logging in simultaneously, then 3 users, and so forth up to 10% of the population. If you find timeouts or locks - bring your results to Dev and Business.
Staging environments are critical, especially for companies that deploy to customers through scalable web interfaces, and they provide a small way to test a large, but not complete subset of issues in an 'as close to production' environment as possible without interfering with customers.