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.
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?