Test Environment Management Metrics

When it comes to testing and quality assurance, providing the right incentives and metrics is critical. Your release plan shouldn’t reward quality assurance and quality engineering teams for rushing systems through the QA process, and you shouldn’t create systems that penalize anyone for identifying bugs or other issues that will affect quality. Quality and appropriate testing is crucial, especially in industries that deal with critical safety and security systems.Test environment can take any number of forms. For a critical system you might have several kinds of test environments. Some are permanent while others are only needed at specific points in the process: Development Environments – Some might not consider these testing environments, but the developers consider these essential to quality. Every development group expects to have a system up and running all the time, built in response to activity in an SCM system. This is usually the system a developer will use to run continual tests to ensure code quality. Quality Assurance Environments – Some organizations only QA systems before they go into production, but the top performers see QA as a constant. QA engineers and testers should be constantly testing code as it is developed, and this often requires a second environment that is more stable than the Development Environments. Staging and Integration Environments – While one large development group may have separate Dev and QA servers, when it comes time to integrate these systems into a whole you need a separate staging and integration environment, which might change infrequently in response to large release events requiring widescale collaboration. Performance Testing Environments – It is a best practice to isolate your performance testing effort from other QA functions, as performance tests often make a system unusable for anything other than load testing and capacity planning. Production Standby Environments – If you need to push an immediate patch to production, you will need to have a system that matches production available at a moment’s notice. [you will need a production system that can be available at a moment’s notice.] These are often emergency systems that are used rarely, but when they are used they are the most important environment in the organization. It is common for organizations to take a calculated risk and repurpose these environments for QA and testing during a major release.For a large organization you might have several application groups using 30 or 40 environments, and for a complex application each environment involves databases, caches, services, and other systems. A proliferation of environments is often the driving factor behind ballooning IT budgets, as hardware and systems add up quickly.Here are three critical metrics to consider when you approach the task of configuring and supporting test environments in a release management process:1. Environment EfficiencyThink of an environment like you would think of a gate at an airport. How often is an environment used? How often it is the center of demand conflicts? If a particular environment is a point of constant conflict you need to perform a detailed analysis to understand its impact on your release plan.Using Plutora you can review the past several releases and identify trends in environment efficiency so that you can make informed choices either in provisioning new environments or telling your IT department how many systems need to be budgeted for or provisioned. If you are constantly fighting a battle for resources, use Plutora to shine a light on the problem and gather data about how environments are affecting your release timelines. This is often the best way to convince management to invest more resources into infrastructure for testing environments.How often is an environment a focus of contention or a dispute among teams? How many times in a given release cycle does testing or development have to stop because an environment has been reclaimed by another project or group?2. Environment StabilityIf your testing environments are constantly affected by outages and unavailability, your release timelines will be affected. You can use Plutora to measure stability events for specific environments so you can pinpoint and plan around events that will affect your critical path to release.How often is an environment unavailable due to factors within your project’s control? How often is an environment unavailable due to external factors? Is the software and hardware in an environment up to date with the target production systems? How often do you have to resort to manual workarounds due to an environment?3. Environment Agility“How long is it going to take to set up the QA system for this release?” and “Why do we have to run another sync with production for our performance environment?” or “How long is it going to take to build this environment in OpenStack?” In an age of Big Data and cloud-based infrastructure we’re still waiting for environments to be created and configured.How quickly an environment can be created and configured is a measure of its agility. If an environment needs to be retooled to match another code branch or release or if a system needs to be verified and validated before a release can be deployed to it, these are all tasks that need to be modeled and captured in a tool that understands how environments affect releases. Plutora can do just that. You can factor in setup and configuration time so that you don’t just assume that environments are going to be ready when they might require days of effort to perfect.With Plutora, resource and environment planning is an important part of the planning process for a release, and our customers have come to view Plutora as more than just a tool to be used to plan a release. Our customers use the data from Plutora to guide decisions about IT budgeting and procurement so that management understands the true impact that issues with environment quality and contention have on the process.