Poor test environment management is often the common denominator when testing on large-scale projects or programs slips from the test schedule. This is normally one of the high percentage root causes of slippage amongst the other usual causes such as bad requirements, overly buggy code, and resource constraints.

Rarely do projects operate without having test environment issues. As organizations mature their IT application suites grow increasing integrations points and data complexity. This always introduces end-to-end knowledge gaps around dependencies in both setting up and managing test environments.

Complex integration points need to be replicated in test environments in order to adequately perform representative progressive and regressive testing of production scenarios. As code drops and configuration settings get deployed, managing the code and configuration between each environment and their respective components becomes extremely difficult. It only takes one missed configuration item and the test team has down-time which can put a significant dent in the test schedule. All too often on projects it happens over and over again.

A Five Point Plan for Test Environment Managers

Here are five points which test environment managers can look at refining to minimize environment down-time and improve their working relationships with test teams.

1. Refine your Test Environment Management Services (TEMS) Processes:

Over the last half-decade many larger organizations have opted to outsource their TEMS practice to multi-national IT consulting firms. This has been a sensible approach because these IT firms bring with them experience, processes, and sometimes custom tools. Though, the major challenge is that their processes can be top heavy.

Reviewing the process to see what is working and what is not is very important. A simple way to approach is to do a review of a recently implemented project and looking at how many of your existing TEMS processes were followed. You will be surprised by how low the number will be. There is no harm in version controlling your TEMS processes and constantly making improvements and sharing the improvements with your colleagues.

2. Implementation of Access Controls:

In most enterprises the testing teams are not the resources performing code deployments, server con figs, data refreshes etc. However, test teams do often have access to perform technical procedures like above which bring introduce risks of accidentally making un-qualified changes.

A quick fix is to implement access controls over the test environments so that the test team and vendors can only access components relevant to them performing their day to day job.

3. Managing Test Environment Communication & Contentions:

Lots of projects means lots of test environment logistics to manage. Competing project requirements translates into tracking which environment is pointed to which integrations and what codesets & datasets reside at different application layers. Often spreadsheets are the tool of choice for managing all this data which spells disaster when you have competing projects all vying to use the same test environments.

4. Implementing a Test Environment Management toolset:

This can dramatically improve how contentions and competing requirements are managed. There is no use having a excel spreadsheet kept on the file share somewhere if people can’t access it. Find a TEMS tool which allows you to model and implement processes, you will find immediately all your colleagues will have a greater application of what you’re trying to achieve.

5. Enforcing a Low Touch Change request (CR) Process:

Test environments are not managed with the same rigor as production. I totally agree that non-prod environments need more flexibility but where problems arise is when changes are made to the test environments on an ad hoc basis without any form of documentation for auditing and governance purposes.

Implementing a change ticketing system can easily be performed. I would highly advice against using your production ITSM tool to do this because usually production protocols can get pushed on you for using a ITSM toolset which create overheads.

Manage Configuration drift by properly documenting the changes made against each environment. Without an audit trail untangling configuration drift will become time consuming and expensive.

To understand where your organization sits in relation to the maturity of your environment change ask yourself one question, “Can I easily track what changes to environment x have been made and what is the current configuration/application version of that environment?” If the answer is not a definite yes then the writing is on the wall as to why you may have environment issues all the time.

This Stuff Costs Money

No doubt about it, test environments are extremely expensive to run especially when you have integrated environments that replicate production. You have the cost of licensing, infrastructure, and resourcing. While virtualization has reduced costs associated to infrastructure and time to market, the cost of application licensing and resourcing is on the up.

Regardless, of whether or not you work in the public or private sector, getting budget to spend on new environments is often not a reality. This means managers need to get smarter and more innovative around how to do more with current environments. Implementing a few of the concepts above is a great way to aid in your TEMS success.

About the Author

Sean Hamawi has 10 years product development, execution and delivery experience within some of the largest organizations in Asia. Prior to co-founding Plutora, Sean was executive director of Tenstone, a niche professional services company that gained a reputation for strong execution and turnaround capability within large IT programs at clients such as Lloyds Banking Group, National Australia Bank and MLC. Earlier in his career Sean held team leadership roles in product development, release management and test management at Macquarie Bank. Sean is focused on the product vision and execution and holds a Diploma in Software Development.