Testing in a Squeezed, Squeezed World

driver, the more chance you have of getting where you need to go. The more fuel you put in the car, the longer it will go for.

So at one end of the scale, we have a project with a thimbleful of fuel in an old Model T Ford on a narrow, dirt road that leads to nowhere and no map.

What about the other end; a petrol tanker equipped with a GPS and nitrous oxide on an autobahn with the passengers tied to the roof and Schumacher at the wheel!

What Can We Do To Maximise the Potential for Success. Making the best possible use of the resources at your disposal can increase your chances of delivering a successful project. This will require a certain amount of creativity and a neversay-die approach on your behalf.

Risk Analysis The documentation will (should) tell us what we’re aiming for. However this alone does not usually qualify us as experts in what the software should be doing. We often need to get our callous-less IT hands just a little dirty by digging into the requirements and/or the business and unearthing the things that are really important.

In addition, looking at past exercises can help determine what has gone on before and help to determine where the likely problem areas might be.

Lets look in a bit more detail….

If the deadline is looking insurmountable then focusing on the areas that really matter can assist in bringing a semblance of reality to the effort. This is commonly referred to as Risk Based Testing or in simpler terms, Do-The-Important-Things-First Testing. Let's have a look at some of the key points.

Before we can assess risk, we must know what our test initiative will comprise of. This can be determined by following the traditional method of testing, which in simplistic terms, looks something like this:

I do not wish to trivialise this process, it should be at the heart of all testing projects, however we won’t be going into the semantics in this session. I’m sure we’ve all been exposed to it in some form or another and needless to say, the more closely this process is adhered to, the greater the chance of success.

Risk assessment is best started as early as possible in the system development lifecycle then broken down further through the rest of the process. Usually in testing the first area for risk assessment is the test requirements, which can often be taken from the business risk assessment (provided one has been performed). Be sure to cover the lower levels, for example, it may be critical to determine the overall risk covering a certain test requirement however the test cases within that requirement may be assessed with differing priority levels.

As a loose guide however the following points should be included in any risk analysis (I use the word 'module' below to mean an entire system, a sub-system, module, function or even a single calculation):

Customer impact and visibility —what will be the impact on the customer if this module doesn't work or is flawed?

Business operational risk – —will problems in this module present any risk to internal processes. There may not be an immediate impact on the customer or he may not ever know there is a problem.

Frequency of use —is this module used frequently and/or repetitively?

Prior defect history —has this module had a history of problems?

New functionality —is this module completely new?

Modified functionality —has this module had a reasonable level of modification made to it or does it contain new functionality somewhere within it?

Pages

About the author

Based in New Zealand, Geoff Horne has more than thirty years of experience in software development, sales and marketing, and project management. He founded and ran two testing companies which grew to enjoy an international clientele. In 1994, almost by accident, Geoff found himself involved in testing a complex fault management system that led to further testing assignments covering a wide range of applications and tools. Of late, he has focused on a few select clients running complex test projects in a program test management capacity. Geoff has written a variety of white papers on the subject of software testing and is a frequent speaker at testing conferences worldwide.