Bruce F. Webster: Software QA Hierarchy

By Bruce F. Webster Print this article Print

You would think, given the dollar amounts at stake in information technology projects that every effort would be made to ensure that the quality of the software was handled by best practices in quality assurance (QA). You would be wrong.

The full technical hierarchy is something like this:

  • Enterprise architect
  • Chief software architect
  • Some other kind of architect
  • Senior developer
  • Developer
  • Tester (I prefer the term “QA engineer”)

And in most organizations, “testing” really is at the bottom of the totem pole. Often, a senior, highly experienced QA engineer will have less credibility and status within the IT organization than an entry-level, still-wet-behind-the-ears programmer fresh out of college.

There are, I believe, several reasons for this. First and foremost is that QA, as stated above, is often defined simply as testing, and many organizations hire non-technical personnel to do software testing. They figure it doesn’t take a college degree – at least, not one in computer science – to sit in front of a computer and step through a test script.

On the other hand, you can train a lay person to conduct medical surgery, but I suspect few of us would want such a person to operate on us. An IT engineer doing testing is far more likely to know what’s going wrong and will usually be more likely to be able to recreate the defect (a key point in testing).

Second, just doing “testing” – especially if it’s just running a test script – is ultimately boring for most software engineers, particularly the talented ones. They want to be creating or implementing programs, not figuring out where someone else goofed up. Again, the problem is the rather limited view of testing – running user-oriented scripts against a written requirement – taken by many organizations. Many other types of testing exist, all of which can be valuable and quite a few of which are vital. Most of these other tests do require software engineering skills and real expertise.

Third, many organizations have no careen path in quality engineering. Instead, they have a pool of “testers” and a head of QA. At best, they may have some mid-level QA managers. But there really is little opportunity for professional advancement – except to move over into software development.

Fourth, as noted above, QA tends to be an afterthought in terms of budget and other resources. It is often the first area within IT to have its funding cut and the last to have its funding increased.

As a result of all this, a job in QA is usually seen as being an insecure, dead-end position. And the result – as Weinberg noted – is software that’s anything but reliable.

Bruce F. Webster is a consultant specializing in reviewing and rescuing large-scale IT projects. You can reach him at bwebster@bfwa.com or via his websites at brucefwebster.com and bfwa.com.  [© 2008 by Bruce F. Webster]

This article was originally published on 2008-09-11
Webster is Principal and Founder at at Bruce F. Webster & Associates LLC. He works with organizations to help them evaluate troubled or failed information technology (IT) projects, or to assess IT systems and products for possible investment/acquisition. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan.
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.