Testing some flexibility into a project

It always amazes me how often testing is, if not overlooked then at least barely considered, when planning and costing a project. I’ve been guilty of it in the past, and trust me, I got hurt. And while nothing can repair a badly specified application or getting the user requirements completely wrong, without decent funding for testing of your beloved project you are invariably heading for failure.

Indeed at the start of any major development project I would seriously advise a huge chunk of money be allocated to testing. There is the obvious reason of ensuring the reliability and functionality of the finished application, but having allocated a decent percentage of the overall project budget for the last phase before implementation will do another couple of things.

First of all it gives you an all-important buffer for when development runs over-budget and you need a little extra resource or finance to help get it back on track. Of course you should have factored in an allowance as a buffer, but a little extra is never a bad thing. But, and this is vital, ensure you always know exactly how much you will need for the testing itself and never take money allocated for actual testing away.

The other thing additional testing budget gives you is a timescale buffer. If you have given yourself an adequate testing budget, i.e. enough money to employ an outside test firm and the ability to throw resource at the problem, then the traditional panic-squeeze on testing becomes less of a liability and more of an opportunity to keep your project on target. Testing is one of the project elements where there can be a significant degree of fragmentation of work. It is relatively straightforward, if you have a decent test manager, to segment the test streams in such a way to make additional resources significantly effective.

The key is to ensure not only do you have effective test scripts, which should have been designed in conjunction with the business analysts who wrote the original requirements, but you also have coherent and simple regression testing procedures and reporting systems. Bugs need to be reported efficiently, fixed, regressed and then fully tested in a clear and open manner. The test scripts should also be designed to ensure that a logjam does not occur when a bug prevents further work on a particular script.

If your test manager has done his or her job then you should be able to compress test schedules without impacting the quality of the test process and without impacting the overall quality of the product.

This story, "Testing some flexibility into a project" was originally published by Techworld.com.


Copyright © 2007 IDG Communications, Inc.

Shop Tech Products at Amazon