Testing in a Squeezed, Squeezed World


then a second or even multiple environments could help. You will need to be aware of any conflicts eg. common error logs etc. however these can mostly be managed. You will also need to make sure that you appropriately split the effort across the multiple environments (see below).

If your test system resides on a separate machine, you may not necessarily need another machine for a second environment. See if there is space and/or processing power available on another machine. Make sure any compromises do not affect the integrity of your testing though.

I had a project a while back that used hand-held devices. I was told by the IT team that we could only have one test environment because we only had one hand-held gateway and the test environment could only support one anyway. Problem was solved when I

Isolated environments —there may be an opportunity within your test environment to split off a certain section, module etc. into a separate isolated environment. This environment may subset of requirements. You will need to balance this with any consequences of not having the entire system tested in a single environment and how this reflects reality.

Managed demarcations —this is where a constraint is created by having everyone logged in, all testing simultaneously and the conflicts cause delay. I once had a project where the testers covering the batch processes would run their tests and the response time for everyone else dropped fivefold. While this was a legitimate concurrency test, it slowed performance to the point of causing delay so we changed the schedule to run the batch tests after hours. We could have run them in another environment or selected certain times of the day etc.

Whatever demarcations you arrive at, make sure that they do not compromise the integrity of your testing.

The management and creative use of your test environments often goes hand-in-hand with your people and time availability. It may not be possible to separate one from the other so ensure that if you do go for more people and/or more hours, that you can source any additional environments in a timely manner. You do not want to gain a few days advantage if it’s going to take a week to get another test environment up and going.

Unless you hold the purse strings for your testing project then its unlikely you will be able to make any direct call on the moolah. So probably at best you will be restricted to going cap-in-hand to the powers that be for the much-needed funds to do the job.

There are a few tips and techniques that can help with this great solicitation:

Make sure you have a strategy and plan (including contingencies) —a well-thought out and deliberated plan will convey to your management that you know exactly what you’re doing and that the only hindrance is lack of funds. Cover off any potential ‘gotchas’ and ensure that you include in your plan what you plan to do if your plan doesn’t go according to plan, got that?

Explain the testing initiative —make sure you appropriately convey the testing issues. Clearly explain the benefits of proper testing, including an ROI if possible, to all stakeholders and maybe even involve them in the planning. I’m sure most of us know how to create fear, uncertainty and doubt over the potential calamities caused by a lack of or under-cooked testing. However beware that you don’t oversell otherwise it might be seen that you’re going for the Rolls Royce when the Ford is what you need to get over the line.

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!