7 popular misconceptions we just had to address
Quality Assurance is a field that is currently going through a soul searching phase. People with the exact same title might have completely different ideas about their responsibilities, and those on the outside have even more disparate opinions about what those tester-people do. While we are interested in what QA is, we thought it would be fun to list what we think it is not.
QA breaks things
QA don’t break the software. They break illusions about the software. Unless someone is writing the product’s features or managing infrastructure they can’t, by definition, break things.
QA vs the world
A more generalised version of the first myth. Within teams QA can be seen as the people who point out developers mistakes, frustrate management by stopping releases, and cause a bottleneck in the development flow. These are signs of malfunctioning teams which require systemic efforts from everyone involved.
“Just do automation on the side”
Automation is a full time development job, treating it as a part time one is what makes so many automation efforts fail. Developers are expected to only work on development and continuously hone their craft, why would test developers be any different?
“We have manual QAs you will pair with and in a month they will be writing tests”
First, the whole “automation vs manual testing” debate has already been addressed a number of times so we won’t go deeper into that. A good professional will use the right tool for the job, upskilling as needed, instead of finding the job that accommodates for their tool. The big issue here is unrealistic expectations for people to be able to independently code tests without going through the learning process that other developers did. The unknown unknowns of the managers and those expected to skill up mean that no realistic estimate can be done since learning largely depends on the person’s interest in the topic and lots of practice.
We’re not really involved in setting the requirements, we just test
There’s few contributions for a QA to make that are more valuable than analysing the requirements. Defects found in testing are estimated to be about 10 times more expensive to fix than those found in the requirements phase. Often, this is expressed as "We’d love to be more involved in requirements setting but we have so many bugs to test and retest". Well, you will keep having them until you get involved in the earlier stages.
QA’s main job is:Automated UI Testing, Exploratory Testing, Finding bugs, any other testing activity
Our job is to provide information to the business about the state of the system and highlight potential risks we see coming. How that is done depends on the situation. In reality the actual verification and/or automation usually takes much less than 50% of our time.
QA can somehow be a secondary concern
QA can be the team experts in how to make things verifiable from the start, how to find the breaking cases, teaching other developers to do these things better so the whole team can become good at writing tests, and automate the heck out of it. Furthermore QA is often the bridge between the business and the tech team since they know both the product and the technical issues it’s facing.
Why just let a dev sit there and bash out whatever scripts they can in isolation instead of gaining so much more?
Thanks to Jonathan Taylor, Sven Kröll and Jon Reeve for their inputs!