Common Mistakes that QA Beginners Commit — and How I Learned about Them

In my mind, when I first started working in QA, it went like this: launch the function, try clicking here and there, and see if anything fails. That was it. It took me some time to get accustomed to the fact that there is way more to QA than meets the eye. Essentially, it seems […]

1) “Happy path” testing

At first, I would only do exactly what was said in the task description. Then, if everything worked as expected, I would move to another task.

It seemed quite sufficient back then.

However, after some time, you begin to notice how users interact with software applications in real life. People often enter unnecessary symbols or miss required fields. Sometimes, a button needs to be clicked multiple times before something happens. In other words, the happy path does not seem so happy anymore.

I used to think about whether everything will work if the user does not comply with the instructions at all.

This kind of approach significantly changed my testing strategy. Instead of following instructions, I tried to break them.

And guess what? It turned out to be very effective.

2) Bug reports which do nothing for anyone

My first reports were quite shameful for me. “Doesn’t work on checkout” – sent. Afterward, a few clarifying questions from developers, a bunch of wasted time, and another unreported bug sitting for days. A report should have detailed information regarding reproduction, expected behavior, actual result, environment, build number, version, and if possible a screenshot or video. That might seem like a lot, but once you get into the groove, you spend an additional two minutes per report. No more than that. As opposed to whole threads which waste much more time.

3) Testing without having the faintest clue of what your product does

You can go through the entire app without finding even one major bug if you don’t understand the purpose of your product. It took me nearly two weeks of testing some discount system until I realized that I wasn’t aware how the discount levels functioned. All I checked was if the buttons were clickable – not if math was done correctly there. Reading specification documents, asking questions which sound stupid, observing user sessions – this all completely transformed my testing approach. And knowing what’s “why” helps in understanding what’s risky and thus should be tested.

4) Believing automation can fix everything

There is one phase most beginners go through before entering QA seriously – the stage where automated tests are seen as solution to all issues. They can run as many times as necessary and won’t need any supervision. But automated tests for unstable features break all the time and take more time to execute. Exploratory tests, visual inspection, things that require some kind of judgment – all of those things are hard or impossible to automate. The only question to be answered before writing automated tests for anything is if the situation is stable enough.

5) Holding in information during ambiguous requirement

This mistake might be the costliest one. Everybody wishes to avoid looking inexperienced by asking stupid questions. So, people start making assumptions and create test cases based on those assumptions. Afterward, the product launches, and we discover that we have tested something that should not exist. That’s how I’ve been bitten myself. This mistake happens due to not asking a very clear question: “Exactly what’s supposed to happen in this scenario?” There are certain situations when being silent might be detrimental to QA’s job.

These are not mistakes, but learning experiences. The main difference between a rapidly growing tester and those who stay on the same spot is their readiness to admit what they still don’t know. Tools can change, frameworks can become obsolete, but proper testing is always the same thing.

If you need quality assurance or other technology services, schedule a free assessment to find out how Swan Software Solutions can help.