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