Who Is a Really Good QA?

Tux, the Linux mascot

Hello there! Today I would like to share my thoughts on the topic, which is on my mind lately.

Being in the industry and talking to QA leads and HR, I found out that it sometimes might be hard to hire good QA engineers.

But what makes a QA for a good QA?

Here are a few points that I highlighted as a Software QA engineer with five years of experience:

QA and developers work on the same project with the same goal - get a quality product

QA are not enemies of developers. QA doesn’t aim to “break the product” and then rub their hands together maliciously. QA doesn’t rejoice at the presence of problems, bugs, defects and errors!

QA explores software in order to obtain a product quality status. To be useful to the project, testing must act as a quality improvement process. Bugs are not a product that can be released. Bugs don’t help. Only activities aimed at achieving a common goal - to get a quality product - bring benefits.

And to achieve that, QA needs:

  • understand the goals of the project;
  • take into account external conditions (priorities, deadlines, goals, high-level tasks);
  • be able to figure out: WHAT needs to be done NOW to help the project achieve its goal.

If testing is inefficient, and bugs are found late, then there will be more and more bugs: poor localization of bugs takes time from developers, and introducing them in a non-priority order leads to difficulties in fixing.

Therefore, instead of the task “how can I find a bunch of bugs and abuse developers”, good QA thinks: “What does the project need now, in what format and with what priorities?”.

QA knows how to design tests.

No monkey testing! (it’s useful sometimes, but it deserves its own article)

QA should know how to design tests. To do this, need to know at least what a test analysis is. Depending on the conditions, testing can be carried out exploratively or according to test cases, but tests should not be done thoughtlessly “what will happen if I press this button”, but only according to the results of the analysis: what needs to be tested, in what priority and how it can be done do it most efficiently?

Think first, then test!

QA are masters of communication.

Who, if not QA, has to bear the bad news? The worst thing QA can do when finding a bug is to tell the developer “Well, you screwed up!”. QA needs more than just finding a bug. QA needs to do everything to make it easy and pleasant to fix it. Each developer in the development process can make a mistake, and more than one, but again, QA in the testing process helps to make the product better by finding weaknesses. QA has no goal to offend the developer and poke his nose into the bug.

P.S. There are rare exceptions when developers don’t want to fix a bug in any way. In such situations, you can discuss this case with the project manager and together find a solution.

QA must have an analytical mind

QA engineers with technical background usually have well-trained analytical thinking. Which other QA engineers may or may not have.

In terms of technical skills and tools, a lot depends on the project being worked on. In any case, it is useful to understand the principles of the client-server architecture, version control systems, be able to work with databases and logs. It is important to understand how the web application works and how the API works. Basic knowledge of SQL, HTML, the ability to work with Dev Tools is required. At the start, this knowledge will be enough to effectively test and find the root cause of bugs.


So whether you are already a QA or a fresh graduate considering testing as a career, I hope my thoughts help you evaluate yourself and decide if this field is a good fit for you.

Love your job, learn and you will become the leader in your field!

If you find this article interesting and useful, then don’t forget to share this with your friends. Also, feel free to share your comments/suggestions below ❤️