Do you know the real functions of a QA? Do you know the main difference between QA and Tester? Are they heroes or villains? Let’s go through the most common myths regarding the process of testing and try to debunk them.
1. Tester and QA are the same
Let’s just say that if you think that Tester and QA are the same work position, i.e. synonyms that refer to the same kind of work, you will need to reconsider your opinion. Testing is an activity. Pretty much anybody can do testing. Testing often is merely using a product or a service, whereas QA applies strategic testing, it involves planning how and what to test.
A tester is in charge of testing software during its development phase in order to detect bugs and report them, while a QA performs a set of activities in order to ensure the quality of software during all phases.
2. Testers and QAs can find all the bugs
This is a pretty common misunderstanding. It is not possible to have software completely free of bugs, simply because testing is an endless process. Even if a QA that has an excellent set of skills has tested the application and even if the budget is unlimited and there’s no time limit as to when the testing process has to be complete, nobody will be able to say with an absolute degree of certainty that everything is done and that the app is 100% bug free.
3. Testing can be automated
This is a pretty common belief and to be fair it is partially, but not fully, true. Every test case can be automated but not testing. The automation of tests streamlines the testing process by using specific tools, but an automated process simply will not be able to replace all manual tests.
Automatic tests should start when the software has been manually tested by the tester or the QA and is stable to a certain extent. On the other hand, we must have in mind that automation will no longer work if there are changes in the requirements.
Automation can’t resolve everything. It never did and it never will!
4. They are enemies of the developers
Absolutely not. The delivery of quality products and services to the end users is a team effort. Many people think that testers and developers are destined to hate each other, but it doesn’t have to be that way and more often than not, it isn’t. After all, the overall objective of both is common – to finish the project successfully and essentially deliver quality products/services.
5. Testing and Quality assurance happens when the product is fully developed
Testing depends on the code, so if the code isn’t complete, you can’t do a definitive test. Certain types of tests can be performed even in the phase when the code isn’t done, but these are so-called ‘explanatory’ tests which show us how the development process goes. Explanatory tests can detect certain defects in the ‘embryonic’ phase of development and this is one of the objectives of SCRUM methodology.
The review of the requirements and the development of test cases are independent of the developed code. However, in the case where the development lifecycle is longer than estimated it will affect the QA, so there’ll be less time left to test the fully developed software.
6. With the Unit Test, anybody can test
Those who think unit tests are enough, tend to deliver software with user-interface issues or problems caused by different components not working well together.
It may seem obvious, but unit tests test units. With this type of testing, you can’t test end-to-end flow through an application process, and it’s impossible to test if the user-interface is friendly or intuitive.
The biggest benefit of dedicated, skilled QA or tester is the ability to find gaps in the assumptions that other people may have made. It's part of the tester-mindset to ask, "What will happen if I press the big red button which says 'Don't Push This Button'?" People who don't have tester-mindset aren't as likely to think to test for usability, or whether the system has an intuitive flow.
7. They are programmers that aren’t good enough in coding
This is one of the most common misconceptions about QA. Ok, maybe they are software engineers that don’t like to code, but most probably their ability was discovered by someone who noticed that they have a different mindset. Let’s say that QAs are very smart engineers.
Normally, companies require software quality assurance engineers to have a bachelor ’s degree in software engineering or computer science.
To be a QA you need to understand the software you are working with, programming languages, and certain tools and techniques, as well as using source code repositories, code automated test. You must also be able to understand the agile development process, create test plans, understand QA testing environment, etc. The list of technical skills a QA must have is very long. Apart from the technical skills, QAs must have strong engineering skills and be versed in technology, math, verbal and written communication. On top of that, they need to problem-solvers with strong reasoning and logic skills, but also have practical skills like exceptional documentation and time management capabilities. They have to be creative, insightful, and rational thinkers.
Don’t underestimate the importance of QAs!
8. QA and testers are responsible for the quality of a product
The responsibility of the QA and tester is to detect bugs and report them in order to ensure the quality of the software. They should be able to communicate in a clear way and present their arguments to the other groups involved in the project. At this point and, once all the groups have been properly informed, a decision will be made as to whether the errors in the release will be corrected or the software will be released with the detected bugs. In other words, the job of the QAs and testers is to identify, define and present the potential errors. It is up to the other teams to decide whether and how they are going to fix them.
9. Anybody that finds bugs in games can become a QA
There are a lot of people who think that by finding bugs in games they are qualified to work as a QA. This is absolutely wrong. The role of the QA in the development process is much more important and can’t be limited to finding bugs.
The function of a QA (and a tester as well) begins with the review of quality specifications and technical design documents (architectural documents, requirements documents, help documents, functional documents, etc.) in order to help developers and to provide timely and meaningful feedback.
Only this way, they will be able to understand the overall functioning of the software that is to be developed, its dependencies, as well as the impact of one module on another. This prevents the identification of bugs and helps reduce costs by saving either time or money, or perhaps both. After this, the QA creates detailed, comprehensive and well-structured test plans and test cases that will be implemented in the testing process. They also debug and define corrective actions. Finally, the QA should monitor all stages of software development to identify and resolve system malfunctions with the ultimate goal to meet quality standards.
