Application Development - Baseline
Home arrow Application Development arrow Page 2 - Second-Class Software Quality in Major IT Projects













Renew Your Subscription

Application Development



Second-Class Software Quality in Major IT Projects



By Bruce F. Webster

  Table of Contents:
  1. Second-Class Software Quality in Major IT Projects
  2. Bruce F. Webster: Software QA Hierarchy

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.

Rate This Article:
Add This Article To:

Second-Class Software Quality in Major IT Projects - Bruce F. Webster: Software QA Hierarchy


( Page 2 of 2 )

 

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]



     
     
    >>> More Application Development Articles          >>> More By Bruce F. Webster
     


    Sponsored Links
  • Get up and running in as quickly as 30 days with BI. Learn how today.

  • FREE Securing Smartphones & Tablets for Dummies Book from Sophos
  • 5 New Technologies That Will Change Enterprise ITAdvertisement
  • Build an IT Infrastructure That Delivers the Future
     
  •  
    FEATURED SPONSORED ARTICLES

    FEATURED SPONSORED VIDEOS

     



    LATEST STORIES


     

     


    Advertisement
    rss graphic
           Baseline Newsletters