Failure

I was reading an article (don’t remember where, when [I lie, it was about 2 weeks ago], and who wrote it) about the simple fact that most test automation projects fail. Failing to jump the high hurdle of steep deadlines or drowning in the quicksand of fuzzy requirements and priorities, test automation leads find themselves struggling to keep up with infrastructure, communication, regression processes, and new test development mapping. This can be improved and I’ll delve into my personal plan to address these issues in a near future blog. However, it may not be all that bad…

1. A better, more well rounded tester
When script writers find themselves dealing with environment issues, various test tool intricacies, and other annoying nuances that hold up the actual testing activity, does this not make the tester more skilled? Sure, time is spent on low level details that don’t concern the actual test process but there can be some benefits to this. Ask any Java developer what a pointer is and count how many times they say ‘uh’ or just talk a lot of fluff while taking a crack at explaining. I don’t even think I could explain what a pointer is correctly. Is this a problem? Its not a problem for daily work as my testing role doesn’t necessitate the full knowledge of a C pointer, but isn’t this one of those essential things that everyone in the field of computer science should know about? Similarly, shouldn’t we want testers to understand some nuances of various operating system platforms (that the target application supports) or about the configuration issues in deploying an environment or to just learn in general? I think this makes for a better tester.

2. You learn a lot more about the target app and find more issues in the target application while automating and writing test scripts than when running the regression environment
PERIOD.

Ok, that said, the fact that most automation projects result in failure isn’t a correlation for faulty testing. Automation projects may fall behind schedule (if one is even created), but product bugs can be found along the bumpy road. This also isn’t a justification for faulty automation projects. This needs to be addressed and I’ve seen it first hand and I’ll jot some ideas right after these messages…