Some Myths & Truths about QAs
From my 6 years of QA experience, I’ve heard a lot about how a QA should work.
I followed many of them but later knew that they were wrong. This article is to share some of those experiences and leave some suggestions on how to deal with them.
“QA is like the end user of a product”
Myth. This is still a belief that I see in some professionals. I had this mindset for a long time, that I was like the end-user who uses the product.
If I don’t know how the real user uses it, then how can I think like an end-user? A QA can closely work with stakeholders to identify the targeted audience.
The QA is not the end user of the product. Our role in the team is to guarantee quality, so that the product will be built with minimum failures, which satisfies the end users.
“QA does not code”
MYTH. I remember that, on my first opportunity to automate tests, a dev came to me and said: “We engineers will do the coding and you can focus only on writing test cases and coding is not your cup of tea”.
“ Eww..Really..?”
Days later I prepared the test cases and automated most of them.
“ Wow, That was amazing! “
The point is, there should be no such division in a multidisciplinary team. Of course, all roles have their own characteristics and strengths, but QAs are also part of the dev/engineering team. Your tests is also part of the product being built. And it’s time to change for Dev’s who still think in the traditional way.
“QA has to participate in refinement”
Truth. A pause to explain what refinements are.
Refinements as the name implies, are meetings that serve to refine items in the backlog and detail them better so that they can be ready to be pulled in the next sprint. Refinements are divided into two stages: a business one, with the participation of stakeholders of the product; and technical, with the participation of a technical person (Head/VP of Engineering/System Architect), who can give explanations to the team.
My perception during my initial days was the BA/PO/UI-UX Engineer will prepare the requirement doc (BRS, SRS) and it will be ready while QA starts testing.
But it is a mistake to think that we cannot participate in these refinements. Being involved in refinements help us to write more comprehensive scenarios and give a better vision that perhaps has not yet been observed by either the team or the stakeholders.
The product is not only developed by several hands, but also defined by several hands.
“The stakeholders/dev’s don’t know what QA does / value of QA”
Truth. Because sometimes, we fail to show them the real value of our work.
The importance of QA professionals is often under-estimated and under-appraised. This may happen because of the lack of understanding of their value for the project in general. Really top quality assurance professionals are great assets of any company. They provide serious knowledge of test techniques with a real passion for quality. They can be very persistent in finding even minor faults in the project. They even will manage to make your testing more efficient by making assumptions concerning defects and where they are most likely to be found. The quality assurance team brings a broader perspective to the project which comes from a deep understanding of both development and process business requirements
What can we do then? My suggestion is to metrify our work and share it with the stakeholders or other engineering peers.
Metrify:- presenting graphs about the latest rounds of automated tests, tests included in the release, how many fails, execution timeframe, resources involved, why and what action is taken for correction, among others that make sense for your project.
“The testing starts when development is over”
Myth. In fact, some test layers depend on certain features being developed to be finished. But that does not prevent your work from being advanced.
In projects where QAs mostly do UI tests, I hear a lot saying that they are idle for some time during the sprint and have to rush because the devs release the feature at the very end of the sprint.
Usually, once development is over, comes the famous phrase “only QA is pending”. This ends up putting more pressure on QA’s..
What can you do? Ideally, development and testing activities should be progressed in parallel from start to end of the development lifecycle/sprint. QAs can start with test case and test data preparation. So that you can focus on testing & scripting after the development is over.
References :
Originally published at https://synapse-qa.com on March 8, 2020.
