What is Test Environment Conflict?

May 16, 2016

In an environment where infrastructure is shared across several development teams test environment conflict happens when more than one project needs to use test environment resources at the same time. It can also occur when competing release trains of the same project have overlapping test environment requirements.

Test environment conflict is a common cause of project delays during the later stages of the application development lifecycle and can be one of the main reasons why projects miss critical deadlines. Test environment conflicts cause delays that can cascade across multiple projects and departments especially when emergency fixes for production introduce delays that are passed on to every project currently awaiting access to test environments.

When projects of a higher priority preempt other projects currently making use of test environment infrastructure this can cause delays because of the context shifts that are required to teardown and set-up test environments for particular projects. These conflicts are a common source of tension between different departments and application development projects and can also cause QA to be rushed and incomplete leading to an overall decrease of software quality.

On this blog we’ve discussed the analogy of airport runways and the sequencing of landings and takeoffs for small and large planes alike. Just like an airport runway, projects with emergency releases take precedence over other projects and problems often occur when miscommunication places two projects on the same test environment at the same time. An organization suffering from frequent test environment conflict gives application developers the same experience as being stuck in an airport during extreme delays. Otherwise, productive application development teams are forced to fly in a holding pattern for days or weeks while other projects consume shared resources.

Preventing Test Environment Conflict

https://youtu.be/mTxh76GqIWc

Test environment contention or conflict is prevented by having an accurate picture of the progression of all projects towards release events. Once test environment managers and release managers start using a tool such as Plutora to track project status on a central, consolidated dashboard they can accurately forecast the demand for test environments over time. As projects approach QA, QA integration, and staging milestones test environment managers can give all projects information about availability and possible conflicts in advance to avoid the last-minute test environment surprises that can paralyze an IT department.

The occurrence of test environment conflicts can be reduced through the use of dedicated, persistent environments for individual projects. If a project has a regular cadence of release events it is more likely to maintain a stable set of test environments to support a continuous process of QA and Staging. If a project has an infrequent or irregular release schedule it is likely only able to qualify a production release when a shared QA or Staging infrastructure resource is made available.

As more organizations move towards cloud-based infrastructure and deployment automation technologies test environments can be created and disposed of on-demand by individual development teams using self-service platform-as-a-service tools and configuration management frameworks. In these organizations, test environment conflicts can be avoided by allowing teams to dynamically increase infrastructure capacity on public or private clouds.

While this is an increasingly common pattern, even the most advanced organizations continue to support test environments for legacy applications installed on bare metal servers that are neither agile nor amenable to on-demand provisioning. If an organization is resource constrained for test environments it must use a rigorous approach to planning and forecasting test environment infrastructure to avoid contention and conflict.

One of the primary goals of both release management and test environment management is to avoid delays due to test environment resource constraints. Through a combination of communication, transparency, and metrics test environment contention can be dramatically reduced and exponential gains in productivity can be achieved through the use of tools like Plutora to give all parties an accurate, up-to-date picture of test environment usage and projected demand.

Streamline your software delivery with Plutora!

Streamline your software delivery with Plutora!

Imagine a single dashboard managing all enterprise software delivery, boosting visibility, efficiency, and cutting costs. Experience Plutora's solutions today!

Imagine a single dashboard managing all enterprise software delivery, boosting visibility, efficiency, and cutting costs. Experience Plutora's solutions today!

Deliver Better Software Faster with Plutora

Deliver Better Software Faster with Plutora

Deliver Better Software Faster with Plutora