the manual v. automated testing debate
There's an angle to this debate that I missed during the prevention v. cure series I did last month. It surfaced in a lunchtime conversation I had today with two test managers in our e-home division (these are the guys that test the Media Center PC and other such delights). Michael Friend, a Group Test Manager who's been around the empire far longer than I have, gave an interesting perspective: "you know automation has gained too much of a foothold when your testers feel more vested in their test code than in the product they're shipping."
Ouch, that was aimed at me.
I'm often very proud of my own test code and some of the tools I've built have, to me, been far more compelling than the code they've tested. I've walked this line Michael talks about and apparently fallen on the wrong side. Michael's point was that manual testers, by definition, are closer to the product they are shipping than automation experts. In manual testing we're hands-on and directly involved; in automated testing we build automation that touches our product ... we are a step removed from it. I wonder if there is something psychological at work here that gives manual testers an advantage on passion, insight and product familiarity that makes them more qualified to find bugs. Certainly, I think that connecting closely with your product will make you a better tester and Michael himself said he prefers testers who find the right balance between automation and hands-on testing. The more hands-on testing they perform, the better their automation.
Brent Jensen, who doesn't let his youth stand in the way of being old school, said it best: "when testers treat their automation like they gave birth to it, they've crossed the line."
Parents are often the only ones that think their baby is beautiful. How often have you been bold enough to say, "man that is one uuugly baby!"