There are many misconceptions and myths flowing around QA (quality assurance). Let’s take a look at a few of them.

MYTH: SOFTWARE TESTING IS EASY; ANYONE CAN DO IT

Reality: That is far from being true. The importance of QA professionals is often under-estimated and under-appraised. It may happen because of the lack of understanding of their value for the project in general. This job requires knowledge of coding, analyzing, assessing risks, being familiar with quality standards, databases, and many other non-technical skills (link do članka “Am I The right person for the QA job”).

The job may look easy from the outside, but once you try it, you will see that it’s more than just “monkey clicking.” If you are wondering if this job is right for you read the article Am I suitable to become a QA?

MYTH: QUALITY ASSURANCE CAN BE LEFT TO THE FINAL STAGE

At first glance, it seems logical: we test everything once the product is fully developed. Having a fully developed product tested gives us a complete view of what should be improved or changed. Then we will get rid of all the bugs that we will find, make quick changes, and the project will be ready to deliver.

Reality: If the quality assurance is done in the final stage, there is often very little time left. The team is in a rush due to the previous delay during planning or development. They want to launch a product on time, so the testing period is often shorter than it should be.

And a result? Fully developed software with several bugs left because there was not enough time to test it properly.

MYTH: QUALITY ASSURANCE IS TOO EXPENSIVE

Reality: Well, yes. It is not cheap. But let’s be honest: there is no bug-free software. It turns out that it is even more expensive to launch a product with bugs, which you have to fix afterward. If the bugs are found in the early stages of development, they are fixed easier and more quickly, costing less money.

Releasing a product with lots of bugs is also bad for the business. Who wants to hire a team to create another software if there was so much trouble with their previous one?

MYTH: TESTERS ARE THE ONLY ONES TO BLAME IF SOFTWARE STILL HAS BUGS AFTER THE RELEASE

Reality: Testers look for bugs; they don’t create them. Good quality product is everyone’s responsibility. The whole team should work closely together, with the same goal in mind: to deliver the best software possible.

MYTH: TESTERS DELAY PROJECT DELIVERY

Reality: Delays in software development are a common thing. There can be several reasons for it: unexpected problems, requirement changes, inappropriate time limits, etc. And yes, sometimes some complex bugs are found, which affect several other software features. It can take a lot of time to fix them and then do all the necessary testing.

But severe delays usually don’t arise in teams that had done pre-planned test cycles. So testing does not delay projects, but incorrect planning and unreasonable expectations do.

MYTH: DEVELOPERS AND TESTERS ARE LIKE OIL AND WATER

Reality: Developers work hard to make the best code possible, and a testers’ job is to challenge the code in every way possible. He does that so that the application will not break when it’s released in the live environment.

Sometimes, there can be little tension between them because it can be hard for developers to accept that they made an error. And the testers, sometimes (too) happy they found a mistake, report this insensitively, in a victorious way, leading to a battle.

Developers and testers are not enemies, but they both have to realize that. They are in the same team, and they fight for the same purpose: to deliver the best software possible.