Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Who is a QA?

Who is a QA?

Most organisations wish for a quality product but, paradoxically, very few give importance to hiring the right people for testing and investing in their growth. Other organizations feel that the quality of the product lies in the hands of the QAs and it is the QA’s sole responsibility to deliver a “bug free” product.

In both of these cases, quality is not a priority from the beginning. This results in poor quality service, defects identified further down in the development process, longer cycle time and consequently longer time to market. 

It is widely known that the later a defect is found, the greater the cost of fixing it. In this scenario, developers have to switch context in order to understand the logic before fixing the defect. This would take longer than identifying the same defect whilst the developers were working on that feature.


In most software development engagements, QA is an acronym for many words - Quality Analyst, Quality Assurer or even a Quality Advocate. In some organisations you will also hear the word Tester, Automation Engineer etc


Irrespective of the terminology, we have to ultimately understand the goal or objective of this person on the team and the value they bring. 

In many cases I have experienced, people playing this role think that writing automated tests is all that this role has to offer. They would be happy scripting away automated tests for every feature that is being developed. I would ask myself “Can developers script the same test code? If yes, what is the value that I am bringing as a QA”. Moreover, focusing just on writing automated tests would lead QAs to mostly catching defects once the product code is written. This is a reactive approach. 


The core value that a QA brings to the team is the mindset which includes various

attributes based on personality. It is like the mind of a seeker. 

Someone who is


  • Curious and inquisitive

  • Lateral thinker

  • Thinking in an analytical or critical way

  • Questioning the obvious. Questions that may sometimes lead to more questions 

  • Not taking things for granted, nor is led by assumptions

  • Observant and mindful of the environment around them

  • Consciously unbiased in their thought process


Anyone in the team who has this mindset can play a role in thinking about Quality of the product. You can call a Quality Analyst, someone 


  • Who ensures that we are building the right product, keeping the customers in mind by analysing the requirements, taking part in user research, challenging the value of the features to be developed and raising any risks. We call this Shift Left Approach

  • Who sees that we are building the product right by validating that these requirements are being met and observing user behaviours through production metrics? We call this Shift Right Approach

  • Who inculcates the values and practices of building a Quality product to everyone on the team 

    • By actively pairing with the business to understand their needs, explore different possibilities of an outcome and build strategies accordingly.  

    • By pairing with developers it would help them understand the thought process of the approach to testing the system. This would enable them to drive testing the system in the future. 

    • By pairing with all other roles frequently, to bring a shift in the mindset of the people in the team to think differently. Thus making everyone on the team responsible for Quality. 


When this happens the team starts looking at the holistic Quality of the product in a continuous and iterative manner. People across the team will start testing the Quality of the ideas being generated, the requirements being captured, the product artefacts being produced, the processes being followed and the customer experience. This is a proactive approach. 

So who is a QA ? Someone having the right mindset, enhancing the Quality of the product from different perspectives as early as possible and reducing the overall cost of developing the product.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights