5 of the Most Annoying Myths about Quality Assurance

Myths are everywhere in our lives and in our work. We face them, we argue them and we are used to them. You are probably aware of some fun facts about IT specialists. If you are a tech-savvy we bet that you have heard the annoyingest question: “Can you repair my computer?” Imagine hearing these kinds of funny myths from a colleague, who seems to be aware of your responsibilities, but still believes in “fun facts”.

There are career myths and misconceptions that need to be talked about and dispelled as much as possible since they are holding people back from growth and cause artificially fed problems between team members. We will speak up for QA engineers and try to dispel the 5 most annoying myths about the testing and quality management itself. Now let’s go and bust some of QA myths together.

People can be divided into three groups: those who find testing easy (high tech humankind), those who find testing hard (non-tech aunties) and personally QA engineers. As we mainly deal with the first group of people being QA specialists we face the common myth about ease of testing more than any others. “Anyone can do it”; “You don’t need any special education”; “Manual testing is just monkey clicking”.

Some people actually think testing is one of the easiest parts of the SDLC. It appears to be easy as there are no touchable results of testing. Product quality can’t be stored, committed and/or transferred. A lot of people think that manual testing means randomly clicking different parts of the application and exclaiming “eureka” when finding any possible issue. Among hundreds of techniques, there is a test technique called “Ad hoc testing” or “Monkey testing”. The aim is to monitor system behavior with random actions. Most people are thinking of this method when they talk about testing in general.

People think that Quality Assurance is easy because it does not require a lot of technical skills. Seriously? Can you be a doctor without knowing where the leg is and where the head is? Actually good QA engineers have loads of knowledge both of quality standards and products they are testing. Testing also requires knowledge of coding, version control, databases, user experience. But, first of all, software testing requires passion, and not everyone can excel in it. Here are some responsibilities of the average QA engineer during a workday:

  • Planning
  • Creating test scenarios
  • Analyzing
  • Reviewing
  • Executing tests
  • Inspecting
  • Reporting
  • Prioritizing
  • Assessing risks
  • Finding root causes
  • Suggesting improvements
  • Retesting

And this is yet the shortest list of our duties.

Also, there is a misconception that QA is a good trampoline to jump into IT-sphere easily. It is not the case! Maybe you can enter this field more quickly, but to get higher you need to be a good specialist. Otherwise, you just stuck in the entrance.

Do you still believe that QA is an easy and non-technical profession?

“Are QA engineers just people who find defects before the end-users?” A big bold NO. We hate bugs as well as any other specialist and user. We simply love preventing them, controlling them and making sure they are found and safely fixed. We do not tolerate bugs. That’s why we can’t sleep if the application is not tested according to requirements and every known issue is fixed as required. Being an error hunter is one of the “10 ways to fail as a QA Engineer”.

Here comes the main difference between the tester and QA engineer. The tester is responsible for just finding bugs (as many as possible). QA specialist, on the other hand, is responsible for planning how to prevent issues, how to find issues more efficiently, how to make sure they are fixed successfully and are not affected on the other parts of the application, how to raise quality knowledge of the other team members and how to improve quality beyond excluding system defects. Testing is a process of system exploration and defect finding, while quality assurance is about ensuring good customer experience.

Besides, when minimizing quality assurance to simply error hunting, people artificially foster the escalation of the “Tester vs. Developer” fake conflict agenda. QA specialists are treated as people who are trying to find not the system but the personal failures of their colleagues. We are not enemies, we are on the same side of the river. Quality is the whole team approach, and it is impossible to be reached without a developer, project manager, support team, etc. Yes, we do error hunting. But it is just a tiny part of our job and responsibilities. Similarly, we don’t assume that Project Managers are just “story writers” or Developers are just “coding guys”.

Women are naturally better at managing multiple tasks, they recall information more easily and tend to notice and remember the details, they are more communicative and empathic. These characteristics are vital for QA engineers for sure. But testing also requires strong analytical and critical thinking, problem-solving: characteristics men are most proud of. So how can people even try to decide which profession is more suitable for men and which one for women?

Some QA dudes feel a little bit uncomfortable. These feelings derived from the first myth we have mentioned: “quality assurance is easy (and boring)”. Guys, there is no job for women or for men. If you like the job, it’s for you.

There is also a common misconception that QA engineers earn less than other IT specialists. That’s why in some countries women are more eager to become QA specialists than men. “Gendered” jobs are now on the decline, though stereotypes still remain. But, to be sure, highly ranked QA engineers are always in great demand (if you know what we mean).

Excerpt from an interview:

-What did you study?

-Applied Mathematics and Informatics.

-So why did you become a QA engineer and not a developer?

One of the most annoying myths we face all the time. QA engineering is seen as something temporary before switching to software development. The most common question in job interviews is about future plans of becoming a developer. Imagine a software developer that is asked about future perspectives of becoming a QA specialist. The truth is they are different jobs with different skill sets. Being a QA engineer is not about being someone else, it is about being a QA engineer, doing what you love.

There are two types of minds: one that loves to create a structure and the other that loves to challenge the structure. The latter is more typical for QA specialists. You can be technically skilled and yet love to explore and challenge the system. Software development is not the logical sequel to the testing. You need to change mindset to switch to software development. Even test automation and development is a part of challenging the existing system rather than building a new one. On the other hand, a QA engineer with a developer mindset can easily fail at testing ignoring negative test cases and just making sure the system behaves as required.

When a developer fails it is about being a failed specialist not an opportunity to switch to “lower-tech” engineering. Becoming a good specialist always requires hard work but never finding a painless way to master appropriate skills effortlessly. The only free cheese is in the mousetrap.

A huge legend about the death of manual testing, right? The truth is both manual and automated testing have different problems to deal with. Automation is mostly for regression test while manual testing focuses on the exploration of the system.

The role of automated tests is extremely important nowadays. It reduces time and resources by excluding dummy and repetitive testing, thus opening space for more sophisticated manual test scenarios. God save automation testing, but there is no automation for error guessing (the key is the experience of the QA engineer), UX testing (the key is empathy and understanding of users’ feelings and comfort), Ad-hoc testing (the key is the creativity and tenacity of the QA engineer), risk assessment, etc..

Manual testing can’t be completely replaced as long as product end-users are people that have needs and requests. Nothing can replace the human touch.

Now you know a little more than your companion. Use this info to bust the myths you face with. Here, In Flux Technologies we could dispel many of these myths cause we behave and work not as “error hunters” or “system breakers” but rather as caring team players who do their best to raise the quality consciousness of everyone in the team and ensure the great customer experience.

Young and enthusiastic tech-talents sharing their feelings and insights about different topics…