Testing, Test Engineering, Quality Assurance?

A couple of months ago, a colleague of mine and I hijacked a regular sales conference call.  So one moment we're talking about open sales leads and client situations and the next moment, the conversation veered around to how we needed to revamp our Test Maturity Assessment offering.

That's when we started to argue whether or not our existing service offering (built around Test Process Improvement - TPI®) should be rebranded as the Quality Blueprint. This is no innocuous discussion, because in effect, we were debating whether it was Software Testing or Quality Improvement we offered our customers.

Now I should possibly go fully disclosure and admit that I'm from the engineering side of the house, having spent over 13 years in this profession. Sure, I engage with clients all the time and sell them services I genuinely believe are going to improve the overall reliability of their business systems. But I can't see myself as someone only from the sales side of the house. My colleague, on the other hand, was more of a marketing maven. Arguably, he was more wedded to how we'd be perceived by the market. Two individuals, two perspectives.

I don't see software testing as anything but another engineering discipline. Quality improvement and assurance is more to do with the classical "process + people" doctrine. Software testing does not improve quality, it is merely a lag indicator of deeper issues within development and deployment. I see it merely as a harbinger of tidings, good or bad. One viewpoint is around how Quality Control tries to achieve the same thing as Software Testing. History tells us that QC is a means of oversight and stories about of how King John of England employed William Wrotham to surpervise workmanship during the contruction of the English fleet. That's oversight, not engineering. What we do in Software Testing has to do with the design of tests, which, with the advent of complex technologies has become an engineering discipline in it's own right.

I'd assumed that pretty much a consensus of sorts had developed around this subject. After all, what one should call oneself pretty important. Professionals need to be able to define their profession and explain in simple layman's terms to their 6-year-olds exactly what it is that daddy does at work.

I know what I am.  I'm a Test Engineer.

 del.icio.us  Stumbleupon  Technorati  Digg 

Posted by Suresh at 5/10/2008 12:07 PM
Categories: Software Testing
 

What did you think of this article?




Trackbacks
Trackback specific URL for this entry
  • No trackbacks exist for this entry.
Comments
Display comments as (Linear | Threaded)
Page: 1 of 1
Page: 1 of 1
Leave a comment

 Enter the above security code (required)

 Name

 Email (will not be published)

 Website

Your comment is 0 characters limited to 3000 characters.