Manual Tests Undermine the XP Testing Practice


If you know someone is going to be constantly scrutinizing the system looking for defects, the temptation to skimp on the unit tests can become irresistible:

Bob: "We'd better go back and add some unit tests for formatRecord before we add this format."

Ted: "Yeah, but John's checking each one of those displays in manually. He'll see it if anything isn't right, and if we don't finish this today, the story drops out of the iteration. I mean, you're right: ideally we should, but if we have to choose between delivering functionality to the customer and duplicating a test he's doing anyway, I say we serve the customer."

Hopefully, Bob will bring Ted to his senses and they'll write the unit tests first. The discussion could be avoided altogether if they weren't counting on John to eyeball the output of the module. It's amazing how good you imagine a manual tester is going to be when you're counting on his talents. Best case, it's approximately as good as you, the programmer, are when you look at the output from a module to find a particular defect. Maybe it would be this good if John were looking at just the one module, one time, for that particular defect. Now take that and spread it over all the modules, for every possible defect, over and over and over again, and you have a realistic idea of what you can actually count on from John.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net