The Anatomy of a QA Engineer


If the development team is the heart of a project, and the product manager is the brain, the QA engineers have to be its bloodline. Without proper QA, the programmer can’t send blood to the brain, and the end result is all too obvious – a failed project.

Being a QA engineer for six years on both software and hardware projects, I can say that the position is, at times, overwhelming. What am I saying? It’s overwhelming all the time! As a QA you take full responsibility of design flaw and bugs even if you had nothing to do with the creation of either. Why? Because it is your job to find it and reproduce it. Most QA’s are not programmers, nor are they product managers – they’re the middlemen.

You see, the job doesn’t consist just finding the bug or defect, it’s about presenting it in a way that a programmer finds useful and a way that a product development team can understand. Those are two different languages. Using the wrong language creates noise and is not helpful for anyone.

There’s also the case of over-communication. Too much communication causes misinterpretation, while, too little information causes vagueness and confusion. The challenge comes down to finding the happy median between too much and too little.

As for my software QA experience, the QA engineering process was something that I created along the way and very little was ever taught to me. At first, I thought that I would simply find a bug and tell the programmer what was wrong. In a hardware environment, this may have worked. The programmer would simply insist that it worked because he could not reproduce it and close the bug. If you let it, this could easily become an endless back-and-forth battle. I had to be very delicate with each and every situation.

The issue comes down to how project teams communicate with each other. Often times, the programmer is too busy to listen and the product manager continues to request further functionality. A filter is needed. There needs to be a way to appease the product manager while, at the same time, not making the programmer disgruntled. This is the conundrum of QA engineering. 

In retrospect, I wish there were more tools available. QA engineers are a busy lot, being the glue that holds a project together. We don’t have time to research and setup new solutions because our performance is based on how many bugs we can close and how many less bugs are in the system. If the heart stops, it’s game over!

I’ll end this eloquent rant with a short list of a few characteristics that – in my opinion – tend to be the make up of a good QA engineer:


It is critical to stay on track with short term and long term goals. Allowing one bug to slip through the cracks due to simply forgetting it will cause more headache later.


The right type of communication is needed in order to convey your findings to an engineer. Your opinion is not wanted on the engineering side, only proof of defects. Your opinion can be brought up with the product manager and/or designer because they are typically the brains of the operation. The product is usually their brainchild, so they can make better use of creative thought. 


Having a thick skin is always beneficial as many QA’s are being pushed by both sides of the ring. Stress management will be needed. Let’s face it, not everyone is a cakewalk to work with, but keeping your head up will allow you to stay focused and not sweat the small stuff.


You don’t have to be a programmer but you need to have the ability to pick up new technical skillsets fast. Once a day, make a point to sit down and learn something new, whether it be learning about code or reading about new tools that can make your life easier. 

What are your thoughts? What other characteristics do you believe a person should have in order to be a productive QA engineer?

See also:



  • Vinh

    You need to be creative as well. There are times when you need to think of new ways to test with the tools you have. Think of new ways improve processes within the team or organization. I agree with being technical. QA engineer need to write scripts or codes to make our testing more efficient.

  • Phil Kirkham

    Critical thinking, creative thinking, quick learner – as covered in this post 
    “As a QA you take full responsibility of design flaw and bugs even if you had nothing to do with the creation of either” – really ? So the rest of the team sit back and point fingers when things go wrong and accept no responsibility ? 
    You’re measured by bugs you find ( and let slip )? Really? So if QA ( as opposed to testing ) has done a good job and put in place a process that creates few defects ( devs doing TDD, tester helping them with stories and tests etc etc ) then you’d end up with a lousy appraisal ? 

  • Tom Walton

    You are not a QA Engineer no matter what your title may be. SQA is not testing. A QA engineer may use test data to evaluate the product (by estimating the remaining defects present after testing is done) but the basic job of Quality Assurance is to give management assurance that the team is following the management mandated process and that all is going well and that the product WILL be really great (or warnings that the development team is left the reservation and that catastrophy is inevitable). This does not come from testing. When testing starts, all the bad things are already built in.

    You are a Test Engineer. You do not have any significant impact on quality. Quality is the responsibility of the people who designed and produced the product. If, as a test engineer, you find a significant number of defects (like 4 or 5), the development team has not done their job. If you find a lot of defects (100 to 10,000) then the product is buggy and will never be anything but buggy even if you spend your entire career trying to find all the defects. Trying to blame you for the defects is like trying to blame the clerk at Starbucks for the chewing gum in the Apple Fritter. It is a totally ridiculous proposition.

    If you want to have an impact on quality (or be fired for being a pessimistic drag on the moral of the developers) make estimates of the number of defects remaining when the next product is shipped. If you don’t know how, send me and email at

    But as a first approximation, take the number of defects found in system test and multiply by 10.

    • Gregory Mooney

      Hi Tom,

      I completely agree with you. When I originally wrote this I was thinking about a project I worked on with the title of QA Engineer. The more I’ve discussed my experiences with other software testers, the more I’ve come to realize that my role was not adequately described. Simply put, I was a “software tester” and not a “QA Engineer.”

      To put this into perspective, the project I was referring to ultimately failed due to poor performance and instability, all of which was out of my control. It was the poor work of the developers and vague product requirements by the project managers that caused the magnitude of defects. Because I was the only software tester on that team, finding all the important defects was a losing battle since there was just too many and not enough time to fix all of them before the release date. Despite the failures of that product and team, it was a great learning experience.

      All that being said and taking your response into account, I feel the need to follow up with a new article about those experiences.

      Thanks again for the comment.