Columns

The evolution of the QA specialist:

• By Tony Baer
• July 12, 2001

Remember the poor quality assurance specialist? The last time you probably saw one was long after working hours. The QA person looked awfully bored, was past deadline, desperately running the same test scripts repeatedly on those 3270 screens to try to break the code, somehow.

Who would want such a job, you probably asked. Traditionally, QA specialists were relegated to the bottom of the heap. It was an awfully tedious job where patience was a virtue. Few developers would be caught dead doing QA.

Your last memory of the QA analyst was probably that person staring at a green screen. Chances are you haven't seen one since, but not because they've grown extinct. Quite the opposite. With the emergence of the Mercury Interactive LoadRunners, SQA Robots and the Segue SILKS, testing has changed into a highly-skilled occupation.

For the neglected testing folks, it is the best of times and the worst of times. We conducted a spot study of the demand for QA specialists. Financially, QA professionals are clearly on a roll. Staff salaries have approached 90% to 95% parity with the same developers who historically looked down on them. If QA folks are brave enough to become consultants, life gets even better. Consulting firms told us they were willing to pay 15% to 30% premiums for QA staff compared to developers.

The downside, however, is that while the financial fortunes of QA specialists have risen, they are still terribly misunderstood. Few organizations yet understand that the QA process should commence at design phase when potential sources of bugs can be minimized. Most development projects are still run like Henry Ford's River Rouge auto plant. Don't disrupt the assembly line. Grind out the code and send defects back for rework later.

Consultant Howard Rubin's 1997 worldwide benchmark report underscores just how fixated U.S. software shops are with quantity. At the pre-release phase, American software teams had over nine times the defect rates of their non-U.S. counterparts. Yet the balance reversed after software was implemented, with U.S. teams reporting about a quarter of the defects. Software may still be better, but only because users are all too willing to be guinea pigs. Any guesses as to when the QA folks probably got involved?

The push to component-based software development has actually compounded the problem, as software teams are further specialized in a manner that would please Frederick Taylor, the father of time and motion management studies. Some organizations are dividing their teams into architects, who design components; analysts, who choose the components for the application; and assemblers, who perform the grunt work. Where does quality come in? As usual, after the fact.

We recently interviewed well over a dozen QA groups, most of whom fought losing battles to convince management to place test specialists on development teams during the planning phase. What is forgotten is that, in the manufacturing world, the Japanese ate Detroit's lunch during the early 1980s because the Big Three regarded quality as an afterthought. The Japanese, on the other hand, designed products for manufacturing, and they made continuous improvement a mantra.

Is history likely to repeat itself with software? Not likely. According to an oft-quoted 1996 survey from the Information Technology Association of America, there are 10% more positions than qualified IT professionals in the U.S., and the situation isn't much better in the rest of the world. Instead, the threat to development teams is more likely to come from outsourcing firms boasting lower defect rates than internal organizations. But the threat is likely to remain hollow as long as there are too few developers to go around.

For QA specialists, the rewards may be better. In the consulting world, they have finally drawn real respect. Otherwise, things haven't changed much. Development organizations are still paying developers to grind out as many screens and visual controls as possible. Problems? Let the QA folks worry about that, and don't bother me, because I'm busy generating the next window.