Pay No Attention to the Quality Behind the Curtain

Dave Kapelanski doesn't want software users to think about quality. That may sound strange coming from the director of field technical support for Compuware's QACenter, a package of automated testing solutions. But let him explain.

"By and large, quality is a hidden thing, and it needs to stay that way," he begins. "Users best understand the importance of quality issues when something goes wrong for them. You don't want a bad experience teaching your customers about quality. Quality should be transparent to the user."

As an example, Dave cites a credit card transaction on a website. The business requirement entails that the company must process a credit card purchase for a specific item. The customer just wants to use her card to buy something. When the system does it correctly, the whole experience is over and forgotten in a matter of moments. But behind the scenes, the system requires correct transmittal of information, accept/return actions, inventory issues, and any number of sub-tasks. And if you really want to be smart about where you invest your testing energy, it also requires knowing specific risks—like if certain cards are favored and should therefore be more rigorously tested to ensure they will work properly. You need to understand the mechanics and focus on the risks so that the user can remain happily oblivious.

In fact, risk is something Dave is encouraging companies to focus on more and more. "Companies tend to come to vendors saying 'What should I do first, second, third?'" Dave has learned that the answers may be different for everyone, but examining areas of risk is the key to figuring it out. He says, "Especially when times are tight, risk is the big issue that should lead the way."

What else has Dave learned from his position astride one of Compuware's leading QA products? "Vendors see what people are going through at a lot of software companies—what is working and what isn't," Dave explains. "Oftentimes, the QA group is brought in too late, making it impossible to really delve into business requirements and identify risks. The QA team is left blind to the business objectives behind the system.” Dave sees that as impeding the ability to verify that a system will effectively achieve desired results.

Time and again, Dave sees that if QA and development had been involved in the beginning with a representative user, everyone could better understand from the user’s mouth what he wants from a feature and eliminate time bickering about what they think the system is supposed to do. "The end result has to be right for the user," he says. "Not the developer or the tester."

But as a director of field technical support, Dave also knows the limitations. "I get bombarded with what people are going through. I've learned that I can't change the world, but I can help point to risks as places to start making it better."

And the only reward for a job well done is that maybe no one will notice.