TOP 10 QA Mistakes — catchy eh?

Mateusz Wietrzyk
Published in
3 min readMay 28, 2018


QAs, as any other human beings make mistakes (read it with Sir David Attenborough voice in your head). Did they learn from it? Yes, perhaps they do but I got a feeling we need quite a few articles like this.

They, I mean we, tend to focus on happy scenarios only

Everybody does. Even devs! Sometimes because they hate their job, because they are lazy bastards or simply because they are not testers. How often have you seen your fellow tester friends checking the positive scenarios without even thinking about the negative paths, not to mention edge cases!

Dear Testers,

I write this letter because I want you to get your shit together and think about other scenarios. Other than the happy one.

Yours forever,

QA Friend

Forget to test multiple browsers and devices

I know, I know. Sometimes it’s not even a requirement. If you ask your client you will end up with IE 6, 7, 8, 9, 11, Edge, Firefox, Opera, Chrome, Safari on Windows, Safari on iOS, every single Android, Windows Mobile and iOS-running mobile device and tablet on earth.

But there is a solution! Narrow it down, agree on the narrowed part and test it. Especially now, when the views come from mobile devices, mostly. BrowserStack isn’t the only option. There are plenty!

P. S. Please use browser and mobile statistics for your awesome PowerPoint presentation which is going to prove your client that 0,03% of the browser market share is not worth the money.

Create test cases that are understandable by the authors only

The title says it all, right? Please understand, I’m talking to other testers reading this part right now, that after you, there might be others, unfamiliar with the system and they need to know how to test it. Please put some preconditions with the links to the documentation at least. If there is none, create one. What you know already can take months for others to pick up. Waste of everybody's time and money.

Afraid to automate

I’m not an automation expert myself, not at all. But the demand for automation testers is high AF. You really don’t need to be an alfa and omega in automation to have something done. There are developers that will help you out. They can create the env or help you set it up. They will show you simple code samples that can be copy-pasted. There are tools that are for automation dummies like myself. Postman, great API automation tool, Cypress OMG! There are not that many for GraphQL, but talk to your devs and figure something out! Don’t be afraid! Do it! Do it now! I don’t know why I’m screaming!

We do not record demos and do not present them to the client

It’s a good practice. Really. Clients love it! Especially when they are not done by Devs. Blah. I mean yea, you present the code and how it works because logs are proving it, but the client wants to see the interface. If it’s just the backend related stuff show it to your Lead Dev and do a code review since you are watching the code together.

Btw when the demo is prepared by the QA it’s a good opportunity to test user scenarios and a way to know where not to click.


I wanted to create 10 of them and I will, but my daughter needs me right now. She wants to cut something with the scissors and we have only the big ones, for the thanksgiving turkey.




Mateusz Wietrzyk

QA, Father, Adventurer, Climber - order may change, depends on the day.