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?
- How to Improve Communication Between QA and Development
- Agile QA Testing – Parameterized Tests and Tracking Agile Tasks
- How QA Prioritizes Bugs