I'm a Tester, Jim, not a QA Engineer!

If you ask any random set of testers what their title is, about half of them will answer with some term that includes "Test" and the other half will answer with some term that includes "QA" and "Engineer".  If you then ask them what their job entails, all of them will say something about testing a product.  Never once have I ever had anybody reply that they are responsible for engineering quality into the product. 

Go ahead, try this yourself.  I'll still be here when you get back. 

See what I mean?  What's up with that? 

If you *did* manage to find a QA Engineer who believes they are responsible for engineering quality into their product, you found someone laboring under some serious delusions.  Or a very broken job description.

I am a Tester.  I am not a Quality Assurance Engineer.  Or rather everyone in my feature team is a Quality Assurance Engineer, because the entire team is responsible for the quality of our feature and the entire product. 

Quality has to be built in from the start.  You can't test it in later.  (You can however incrementally build it in to each new release, which is a good thing if you're staring down a nasty gooey mess and trying to figure out how you will ever tame it.)  The program manager has to write clear specs, the developer has to ensure they understand and can implement the specs, the tester has to look for holes in the spec, and everyone has to be sure the spec is telling them the same things it is telling everybody else.  Once you know what you're building (regardless of whether you (attempt to) get the entire spec nailed down before starting or build it in small chunks), the developer is responsible for writing solid code with no bugs, the tester is responsible for finding the bugs that inevitably pop up and for verifying that the code works like the spec says it should, and the program manager is responsible for keeping the spec up to date and resolving the thought-we-understood-it-but-we-don't problems that always crop up. 

All of this contributes to a quality product.  None of this is more or less important than the others.  Leave any one part out and you can't have a quality product.  Only by working together do you have a chance at that particular nirvana. 

*** Comments, questions, feedback?  Want a fun job on a great team?  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com.  I need a senior tester and my team needs program managers.  Great coding skills required for all positions.

Comments

• Anonymous
  October 27, 2004
  Well I agree with you that if you already have a mess it is difficlut to put quality in a mess. I think if your specs are nailed down accurately, you can avoid the mess but what will happen if you have a product in which requirments are changing often. Team often used the increment requirment gathering process and do the iterative developments. This process makes the whole concepts of quality very relative from the testers point of view. If the requirments are fuzzy how a tester will be able to hold the quality of the product.
  I think the quality is not the spec or tester driven thing. It should come from top management. Mangement should first define what quality is and how much they want it. I have seen product being released in the market as fully tested version while internally team is asked to satisfy only beta level testing. In this respect I can say that the testers job reduced to keep the management happy and not pursuing his passion of testing becasue if he does so he would be voicing concerns which managemt would probably won;t like to listen and which may end up in bad consequences for the testers.
• Anonymous
  October 27, 2004
  Even when you're working iteratively, the requirements for each iteration (or at least the specific story or task or item on which you're currently working) should be very clear. Anytime a requirement isn't clear you had better stop designing/coding/testing and make it clear! Otherwise it doesn't really matter what you do since random typing is as likely to be correct as whatever it is you're doing.
  
  Definitely management has to make quality a priority. If they haven't done so, it's up to each individual to decide how much baloney they're willing to put up with. If voicing concerns about the way in which your product is built and shipped is likely to get you fired, then do you really want to be working there?
• Anonymous
  October 27, 2004
  Braidy,
  Be practical. Nobody want to trade the effort of making THE BEST PRODUCT in the world with the bills they have to pay.Many people are passionate about testing but are asked to follow the managemet decision. I firmally belives that tester should work according to the environment in which they are testing the product. Its not the passion but the practicality that dictates how much and how testing should be done and that is defined by the management. So the crux of the matter is no matter how talented or passionate you are for testing but if you can't keep the management happy, you will soon find youerself out of the establishment.
• Anonymous
  October 27, 2004
  Certainly, a person's situation may be such that they are willing to put up with a lot. Still, if just pointing out a problem is sufficient to get you fired -- if management expects to be a mindless droid that does exactly what they tell you to do and not think about it ways to make it better -- then you should consider whether the benefits you receive from your job are worth the stress and other side effects of working in that environment.
• Anonymous
  October 27, 2004
  Good post. I have found myself disliking the QA moniker more and more and consider myself a tester. If one group has "Quality" in their titles, others may feel that it's "QA's job" for quality and get apathetic about their own testing. Sometimes the "Quality" group become scapegoats. If the whole team are the Quality Engineers, more testing should be occurring, and everyone should take pride in the quality of the product. In many cases, the Quality people are the ones who take the blame, and sometimes deservedly so when they become the "Quality Police". I think Bret Pettichord sums it up well: http://www.stickyminds.com/sitewide.asp?ObjectId=3543&Function=DETAILBROWSE&ObjectType=COL
• Anonymous
  October 27, 2004
  The comment has been removed
• Anonymous
  October 27, 2004
  The comment has been removed
• Anonymous
  February 26, 2006
  Obviously, I have a silly peeve about mixing QA and Test.   They're not the same thing. ...