Most agile test automation is, well, clerical. To borrow an analogy from James Bach, it views testing as something like an inventory clerk at a Grocery Store. "It says here we should have thirty cans of peas. How many cans of peas do we have? Thirty? Good! Check. Greenbar."
In addition to counting them, a real tester would be doing a lot of different things - looking at how the cans are stacked, checking the labels to make sure none have peeled off - "noticing" things that are just not quite right. It's relatively easy to automate the clerical part of testing, but very hard to automate the sapient part.
I find that when I talk about Sapient testing, some people get really uncomfortable. I've spent some time analyzing this, and I think it goes back to Frederick W. Taylor. In the early 19th century, Taylor proposed scientific management, suggesting that we separate the worker from the work. Henry Ford credited Taylor's work as leading to the assembly line, and making Ford a billionaire.
So, hard-coded in the business DNA of North America we have this idea that Management works ON the system, and contributors work IN the system. In that world-view, management is responsible for both eliminating general-cause variation (machines break down periodically, so invent a maintenance schedule) and handling special cause variation like customer complaints.
If management is working on every single exception to the process, then workers should be able to work by rote; contributors should be able to simply follow prescribed procedures. (This is a big part of what Aldous Huxley was talking about when we wrote Brave New World)
The problem is, what worked great for Taylor in 1907 isn't working so well a hundred years later. Today's high-tech technical contributor has more education, depth of decision making, and specialization than yesterday's foreman or line supervisor.
Instead of trying to predict the process, we need to recognize that the white collar worker *is* a manager of sorts. And that's not me talking; I'm paraphrasing the words of Peter Drucker.
What does that have to do with software testing? The best minds in the business are saying that dumbing-down software testing to prescriptive, proceduralized process is foolish. The the same time, the same discussions are happening in the development world, the requirements world, and the project management world.
Still, when I talk about sapient processes, people get edgy. Getting Frederick W. Taylor out of the IS Shop is going to be an formidable challenge.
So let's buckle up. I can't promise that it will be an easy ride, but it certainly will never be boring ...
Thursday, August 02, 2007
Subscribe to:
Post Comments (Atom)
1 comment:
What is interesting to me is that the prescriptive approach seems to be more entrenched in IT than it is in our business partners. I recently taught my business side testers about exploratory testing using charters and they were all over it. They loved it, and they found the vast majority of the bugs in just a few hours of exploratory testing. Afterward, they admitted they wouldn't have found those bugs if they had just followed the scripted tests that had been prepared (test cases that could have been automated but weren't).
I'm not sure why sequential, procedure oriented thinking has such a strong hold in IT. I'd love to see it lose its grip though - we would be a lot more successful.
I like to say that sound judgment and good principles (i.e. testing principles, design principles, etc) all but eliminate the need for prescriptive processes. I wish more people would focus on improving their judgment and understanding of their work and invest less time on prescribing and following rote processes.
Post a Comment