Myths are everywhere in our lives and our work, and for QA engineers too. We face them, we argue with them and we are used to them. You are probably aware of some fun facts about IT specialists. If you’re tech-savvy, we bet that you have heard the annoying question: “Can you fix 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”.
Career myths and misconceptions need to be talked about and dispelled as much as possible. This article speaks up for QA engineers and tries to dispel the 5 most annoying myths about testing and quality management itself. Now let’s bust some QA myths together.
Myth #1: Testing is as easy as pie
There are three kinds of people: those who find testing easy (high tech humankind), those who find testing hard (non-tech aunties), and QA engineers. As we mainly deal with the first group of people being QA specialists we face the common myth about testing being easy more than any others. “Anyone can do it”; “Manual testing is just monkey clicking”.
Some people think testing is one of the easiest parts of the SDLC. It appears to be easy as there are no tangible 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 think 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. 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, and even more technical skills. But, 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 the IT sphere easily. Not true! Maybe you can enter this field more quickly, but to go further you need to be a good specialist. Otherwise, you’ll never grow.
Myth #2: QA engineer is just an error hunter
“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. Preventing and controlling them, and safely fixed is our goal. We do not tolerate bugs. 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). A QA specialist, on the other hand, is responsible for planning how to prevent issues, finding issues more efficiently, making sure they are fixed successfully and do not affect the other parts of the application. Testing is a process of system exploration and defect finding, while quality assurance is about ensuring a 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 try to find the personal failures of their colleagues and not that of the system. We are not enemies, we are on the same side of the river. Quality is a team effort, and it is impossible to reach without a developer, project manager, support team, etc. Yes, we do an error hunt. But that’s just a tiny part of our job. Similarly, we don’t assume that Project Managers are just “story writers” or Developers are just “coding guys”.
Myth #3: Women are better at testing
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 such thing as a job for women or 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 remain. But, to be sure, highly ranked QA engineers are always in great demand.
Myth #4: QA specialist is a failed software developer
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 something temporary before switching to software development. The most common question in job interviews is about plans for becoming a developer. Imagine a software developer that is asked about the 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 your mindset to switch to software development. Even test automation and development are 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.
Myth #5: Testing has to be completely automated
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 tests 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 before. Use this info to bust the myths you’re faced with. Here, at Flux, 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.
