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 (10)

  1. Futura says:

    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.

  2. The Braidy Tester says:

    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?

  3. Futura says:

    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.

  4. The Braidy Tester says:

    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.

  5. 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

  6. …that trackback didn’t come out too well…

    Here are some snippets from the post http://www.testingreflections.com/node/view/1005

    —-

    In I’m a Tester, Jim, not a QA Engineer! Micahel, a.k.a. the “Braidy Tester” covers an issue that I recently covered in my post QA, Testing… what’s the difference

    My post caused something of a protracted and passionate discussion on the agile-testing yahoogroups mailing list including contributions from Bret Pettichord, Brian Marick, Michael Bolton, Lisa Crispin and many more…

    Everyone was in agreement… Software Testing is NOT Quality Assurance… the discussion centred around the reasons why people use QA to refer to Testing…

    The reasons suggested ranged from plain ol’ ignorance (as I suggest in my reference to the “Quality & s-e-x” analogy) through to deceptive “ticks in boxes” so the team can say “were doing QA so don’t need to worry about quality any more” through to delusions of grandure…

    Every time we clarify the purpose of QA & Testing we are correcting a misconception and addressing an underlying issue…

    * If the tester is ignorant about the difference between QA and Testing…. what else are they ignorant about?

    * If the team wants a tick in the box for quality, what short-cuts are they trying to cover-up in the rest of the development process?

    * If the Tester has delusions of grandure, do they have the right mind-set to be an effective tester or even constructive in communicating bugs to the project team, and particularly the developers?

    With the relatively recent increase in the “cool-factor” of testing, I hope there will be more people taking an interest in understanding it and a lot fewer people displaying their ignorance on the issue by calling themselves “QA Testers” or “QA Engineers” when in fact they are “Software Testers” – because that’s what you are!

    Don’t shy away from it… you are a Software Tester, a highly specialised knowledge worker…. don’t shy away from it… be proud of it!

    —-

  7. <p>In <a href="http://blogs.msdn.com/micahel/archive/2004/10/27/248564.aspx">I’m a Tester, Jim, not a QA Engineer!</a> Micahel, a.k.a. the &#8220;Braidy Tester&#8221; covers an issue that I recently covered in my post <a href="http://www.testingrefl

  8. Obviously, I have a silly peeve about mixing QA and Test.&amp;nbsp;&amp;nbsp; They’re not the same thing.&amp;nbsp;…