QA Environments: Why Do You Need So Many?

Standard progression of QA environments, you might need a couple or more in each stage.

During this process, there are often discussions about how many environments a particular project really needs. One project may only have one QA environment while another may have four or five. Environment managers are frequently put in a position of having to ask teams to justify why they need so many environments.

This post is our contribution to this discussion. We’ll offer arguments that show that there are scenarios that require a larger number of testing environments. We’ll start by briefly covering the most common types of testing environments. After that, we’ll give you 3 important reasons to use multiple QA environments.

Then, we summarize the arguments into a piece of general advice, while also granting that they may not be a one-size-fits-all solution. To wrap-up, we cover the brave new world of new hybrid cloud solutions, and how that can affect the QA strategy of your organization. Let’s get started!

Types of Testing Environments

We can’t get to the “why” of testing environments, without mentioning the “what.” Meaning, before we cover the reasons why several environments are needed, we need to understand what the types of testing environments are.

The number of environment types may vary, as well as their exact names. But in general, these are what most people think when it comes to the types of environments:

• Development environment. Used by the developers. In practice, this environment consists of the developers’ machines themselves. They use this environment to—hopefully—unit test their code before it gets to the next stage.

• QA/Testing Environment. This environment is used by testers, QA analysts or other testing professionals to perform many forms of functional and non-functional testing, such as end-to-end testing, load testing, integration testing, and more.

• Staging environment. This is essentially a copy of the production environment. It’s meant to be as close as possible to production, so the team can verify if the application will behave correctly after its deployment.

3 Reasons to Use More Than One QA Environment

1. Teams Are Working on Parallel Development Efforts

If a project has regular releases there’s a good chance that when a development team is finished with a feature, a QA team takes over to validate that feature. During that QA process, development teams often want to move on to the next feature. In these scenarios having two QA environments make sense as features can be delayed and releases will have to be serialized if a QA environment is “tied up.”

2. Long-Term Feature Releases Need to Be Developed While Short-Term Bug Fixes Are Qualified and Staged

If you have a team working on a series of larger, multi-month development stories to launch a new product these efforts almost always require a dedicated environment. These are QA efforts that take months, and require customizations to databases that cannot ship to production. If you don’t have an isolated system for these longer-term initiatives you will be unable to fix bugs as they are identified in a production system.

3. Systems That Rely on Services

If you develop code that relies on back-end services that are also being modified by independent development teams these teams may require multiple environments that are configured to connect to the appropriate testing service. Service-oriented architectures and microservices cause a combinatorial increase in the number of environments required to perform end-to-end testing.

How Many QA Environments per Project?

Considering all of these factors is important when a test environment manager examines the current allocation of test environments. There’s no one rule to cover the number of test environment required, but there a few things to consider when assessing a project’s environment needs:

Projects Sitting in Front of Services Often Need More Environments

If your application fronts a number of services under active development you will have a team that requests multiple QA systems to connect to different releases and versions of these services. If you have a multi-leveled architecture with services depending on other services you’ll see an even greater number of environments required.

Projects Supporting Critical, Customer-Facing Applications Need to Move Quickly (With More Environments)

Projects support back-office operations that can wait a few days to fix bugs often don’t need multiple staging or production environments. Projects that need to respond to customer-facing bugs in hours or minutes these are the projects that need maximum agility and which may require additional environments.

It’s a Trade-Off

Some projects will demand tens of environments to support multi-stream development projects and QA efforts to support continuous deployment. There’s a trade-off between cost and agility, and this is a tradeoff that test environment managers have to be able to calculate and communicate.

Welcome to the Brave New World: Hybrid Cloud Environments

Before we part ways, let’s briefly cover a topic that might represent a big change in the way IT organizations approach their QA strategies: hybrid cloud ecosystems. What would that be and why should you care?

In a nutshell, “hybrid cloud” refers to a cloud environment that’s neither entirely public nor entirely private. Instead, it’s a little bit of both. It employs a mix of on-premises cloud and public cloud services, coupled with orchestration between the two. Why would that present any advantage?

To understand that, first consider the benefits of public cloud services. Why do organizations use those? In short, because it makes economic sense. It’s scalable, relatively cheap, easier to manage, and that’s not to mention the high availability and improved security. I’m sure you could list other benefits. That question then becomes: why do some organizations prefer private clouds?

As it turns out, despite its advantages, the public cloud isn’t the best fit for all scenarios. For starters, there are certain segments of companies that can’t use public cloud services. Think of highly regulated industries such as banks. When it comes to testing, a hosted private cloud with access to real devices might be the best fit.

Hybrid cloud then comes along as a “best of both worlds” solution. The justifications for it are many. For starters, cost. Imagine your organization’s private cloud is already operating at the top of its capacity but there is demand for more. What do you do? Instead of making a big investment in your private cloud, you can use public cloud services to supply the new demand. That way, you have access to the advantages of public cloud we’ve mentioned before, while at the same time keeping the benefits you get from your private environments.

How to Manage More Than One QA Environment?

“There’s no way my team could have managed the rapid increase in release velocity without a solution to manage it all.”
Senior IT manager at the wireless provider – Read the Case Study

It’s easier to manage multiple or in some cases thousands of QA environments when you have a tool that keeps track of environments all the time. That tool is Plutora, and with our Test Environment Management tool, you’ll be able to see strategic allocation challenges in a single, consolidated place. You’ll never have to fire up Excel and send emails to gather this data again.