QA

Myths About QA


Reading Time: 5 minutes

   What’s the very first thing that comes to your mind when you read/hear “QA Tester”? Whether you are a developer, a project manager, a designer, a client, or an analyst; you have probably worked with a QA team… but, are your thoughts really true about what QA Testing really is? Keep reading, and you may discover that what you think about QA is just a myth. Let’s get into it and find out.

Ever since I became a QA apprentice, I have come across several myths which some people think are true about QA’s. People tend to misunderstand the aim of the QA roles, as well as the impact and responsibility we perform on a project. So, by writing this blog post I want to mitigate and bust those myths about QA.

 

 

1) “QA Testers Do Not Know How to Program”

False. Being a manual QA Tester does not necessarily mean that we do not know how to program; I know some testers who know how to program, and they are actually good at it. Some positions such as QA automation do require programming skills and a basic understanding of databases. There are people that start performing manual testing in order to move to automation at some point of their careers.

Which is true is that it’s pretty common to see people from other fields getting involved or showing interest in becoming QA’s. But again, that does not necessarily mean that they do not know how to program. This myth leads to another myth, which is the following.

2)    “Most of the QA’s Have a Different Background than IT”

False. I did some research on my own in one of the biggest QA Communities in Mexico which is called QA Minds’ and the results were the following:

As the results inform, a high percentage of the people surveyed have an actual IT background but that doesn’t mean that only IT people can test. Actually, if you are interested in becoming a QA, but you don’t have an IT background, there is nothing to worry about. As long as people are willing to learn; have motivation, passion, and interest in learning more about this amazing field, that would be a great start.

Many IT companies do not look for an IT background when hiring people for QA positions. Most of them still do only look for IT backgrounds, but it is not 100% mandatory nor has a great impact on the hiring process. This evidently would depend on the company’s statement and/or needs.

3)    “Unit and Integration Testing Is Enough”

False. Unit testing is the lowest testing level, and its aim is to find bugs in small components since it is less expensive to find issues at this level rather than finding them in higher stages or levels. It must be performed every time a change is made in a coding component.

Integration testing focuses on the interaction between two or more components. This is performed by the developers and/or the testers.

Therefore, those two levels of testing are not enough in order to provide quality assurance on the projects. There is more beyond that, there is ‘system testing’ and ‘acceptance testing’ afterwards.

4)    Developers Can Test By Themselves, QA is not needed.

False. According to the “Levels of Independence Testing” developers are more likely to fail at testing because ‘the greater the independence is, the more defects can be found’. This is pretty easy to understand: authors are less able to see their own errors than someone else, in this case, QA testers.

So, in order to keep a higher testing independence, it is recommended that applications should pass through an independent test process according to the following chart which basically shows how the level of independence for each case is.

5)    “QA and Testing Are Performed at the End of the Development Life Cycle”.

Both true and false. Where the answer may vary would be on the methodology used on the project.

If a project is ruled under the Agile methodology, then QA takes very early in the projects in order to be synced up with the rest of the team members regarding the project. Agile reduces the cost of bugs due to the fact that the agile spirit is fast delivery – fast feedback. Unlike waterfall models that place QA at the end of the development process. Having stated this, we can conclude that it depends on the methodology used.

There are times when QA does not take place from the beginning due to management or agreements with the client, or even the availability of the QA team members. And before the product is released, it is when QA testing is considered to be carried out (which is not recommended) since bugs are more expensive to get fixed in this particular case. Still, there are techniques that can be used in those cases, such as ‘exploratory testing’.

6)    QA Testing Is Only Entering Non-Sense Inputs

False. QA testing has its own procedures and methodology that goes beyond just entering random inputs in order to find issues – we might do it at some point, but it is not its core; it does have an actual intention, it is not just a nonsense action.

7)    QA Delays Releases.

False. Projects should not only have their design and development estimations, but it should also be done some estimation time for QA as well since QA should not be considered as “extra time”.  

So, what really delays deliveries is poor project planning or tickets not being moved to the QA queue as soon as they are ready to be reviewed, or even because of the client’s idea of delivering things fast.

8)    Testers and Developers Are Like Water and Oil.

False. In order to achieve better results and high-quality products, QA testers and developers must work closely.

Conclusion

In conclusion, QA is not only a fundamental process in the ‘Software Development Life Cycle’ (SDLC), but it also plays a big role in the whole process, and it should never be underrated or less appreciated. If we all work closely, we can deliver high-quality products and enhance the end’s user experience on the applications we work on, in order to make the customers feel fulfilled and get/attract new ones.

Having said all this, I hope I reached the goal of busting the myths that some people may have on QA Testers.

How many of the myths listed below you thought were true? Is there any other myth you would like to mention? Comment below! I would like to know if there is any other myth.

QA
Why should QA teams know about UX?
Design
The Impact of QA on Design