manager not in an asylum? All of the above and more.
All testing whether it be unit, system, UAT or whatever is ultimately concerned either directly or indirectly, with what the software is going to be used for regardless of whether the need is business-, scientific-, research- or whatever-based.
And to be successful, we must have something to aim for, something that says this is what it should do or this is what should happen. Without knowing where or even what the target is, the archer cannot hope to hit it… and if it is hit, its purely by fluke.
No matter how dramatic a deadline is, if the target is not well-defined then the chances of getting anywhere close are greatly reduced. Hopefully somewhere in the system development lifecycle, specifications have been produced to an appropriate degree of detail for all areas of concern.
We’re not going to delve here into tips for developing specifications or bringing them up to scratch. We’ll assume that you know pretty much what you’re aiming at and have at least some sort of specification or business requirements to springboard from.
It should also be noted that the ideas presented here will work best in a project that is planned and potential shortfalls identified early. Their effectiveness when you’re a week from D-day and only 20% complete is going to be limited although not necessarily without benefit.
We’re also not going to get into the whys and wherefores of test automation. By automation I’m referring to use of the popular record/playback tools and not something that is required to execute your tests. If automation is to work, it requires significant time and investment so I’ve assumed that if you have a tiger-by-the-tail project, that automation is not viable. This is not to say that the principles identified here cannot be applied to an automation project.
What Do We Have At Our Disposal?
- Documentation—the better the documentation, the better chance there is of success. No doubt about it, I’ve seen it proven time and time again. In order to develop test requirements you must know what the software is supposed to do.
- People—testing projects, like all others, will not happen without people. Even in the most highly automated test environments, people are still paramount. We should also include leadership under this heading however more on this later.
- Time—no matter how much business executives would like to think IT projects can be performed overnight, they take time. In theory, the more time available, the better the quality however this is only true if the project is quality focused, well managed and the best possible time utilization techniques are employed.
- Budget—IT projects cost, and many of them cost more than the business might be able to justify. The theory says the more money you throw at a problem, the greater the chance of solving it. However as per above, this is only true if the money is wisely expended.
- Environment/Non-Human Resources —as much as we would like to, we cannot test without something to test on and this includes your application-under-test. Again prudent use of these resources can enhance the chances of success.
If you like analogies, consider this:
The documentation is the roadmap, time is the roadway, the application-under-test is the car, people are the drivers and passengers and the budget is the fuel.
The more accurate the roadmap, the better chance there is of reaching your destination. The longer the roadway, the further the car can travel. The bigger the car, the more people can ride in it. The better the