Software testing and quality are vitally important topics--but they are also deadly dull, real yawners the way most people talk about them. In this column, the author explains why that is so, and offers some suggestions on how to overcome the problem. Basically, he says, people are trying to make a managerial sow's ear out of a technical silk purse.
Over my desk is this plaque. It identifies me as "the premier Curmudgeon of software practice." I'm proud of that plaque. It was awarded to me at a software engineering conference a few years ago, one at which I was appearing as a keynote speaker.
My dictionary tells me that a curmudgeon is a "bad-tempered person." Well, when it comes to criticizing those who get the technology of software wrong, I can be bad tempered, indeed! Even intolerant.
I've just signed up with Software Testing and Quality Engineering to appear, approximately every other month, on these Web pages. Displaying my curmudgeonly impulses. For all the world--hi there, Web page reader!--to see.
Let me show you how curmudgeonly I can be by ungracefully biting the hand that feeds me. This Web page is about software testing and quality, right? Well, I think software testing and quality are about as boring as any topic in the software world!
It's not that I believe testing and quality aren't important. They are important, in spades. Just ask the guy whose poorly tested, low-quality software just caused something to go badly wrong. A space vehicle explodes on the launching pad. Your payroll check has a negative net income figure. We all care, one way or another, about well-tested, high-quality software.
The problem lies in those who try to teach us stuff about testing and quality. If you believed what you read from those folks-textbook authors, conference speakers, consultants pushing methodologies--you'd quickly lose all interest in the subject.
Why? Because most of those folks think that testing and quality are management topics. "You manage quality into software," I can hear them saying. And then they follow that with things like "Testing fails if it's not a well-managed process."
Well excuuuse me, said the Curmudgeon, but I beg to differ. Both testing and quality are highly technical subjects. And the manager who doesn't understand that is doomed to some pretty embarrassing failures.
Let me explain why I feel that way. I'll start with testing.
What are some of the primary topics in the testing field? Things like peer review, and formal verification, and interactive debuggers, and test coverage analysis, and equivalence classes, and statistics-driven testing, and usage profiles, ... I could go on, but I think you're getting the point. Every single one of those topics is a technical topic. Just try holding a peer review with managers present, for example--that's a
human-relations error you aren't likely to make again!
Quality is even more of a technical topic. When quality gurus define the topic, they generally say that quality is made up of attributes, things like portability, reliability, efficiency, human engineering, testability, understandability, and modifiability. Every one of those topics, I would assert, is technical. You'd better be prepared to dip your hands deeply into the technology of quality if you intend to do a decent job of producing a quality product. Who but a technologist really knows, for example, what it takes to make a software product understandable and modifiable?
Gurus are fond of saying things like "You can't test quality into a software project." I suppose, in a perverse sort of way that requires a bit of deep thought, those gurus are probably right about that. Well, then, let me add my own saying--"You can't manage quality into a software project." Not, at least, with the all-too-typical nontechnical software manager.
Do you, like me, find yourself dozing off at the typical software testing/quality presentation? If you do, think about this. It's the management-focused, yadda-yadda-yadda flavor of the presentation that's the problem. Mix in a little