What is the Testing Trap

Don't be tempted to treat documentation and (even worse!) testing as an optional extra that you can do when the development is "finished". This is a sure-fire recipe for disaster. For example, you could fall into the "testing trap". Our typical project plan looks rather like this:

Time

Code

Test

Deliver

Yes, I know it should be 50% code and 50% testing, but do you actually do that? The next thing that happens is that coding takes a bit longer than expected (it does happen), but we still want to hit the same delivery date, don't we? So now our plan looks like this:

Time

Code

Test

Deliver

OK, you tell me. Is this system going to be properly tested? Not only have we reduced the amount of testing, but we know that there were problems building it, so there are probably more errors to find, not less. The only way to avoid this is to plan your testing (and documentation) as continuous (or periodic) activities that run alongside the build jobs:

Time

Code

Test

Deliver

There are several ways you can do this. You can have part of your team constantly working on testing the work of the rest. You can get two programmers to "swap" and test each other's work after they've finished a pair of jobs, or you can alternate weeks of build and testing work for the whole team. It s your choice!

Was this article helpful?

0 0

Post a comment