Top 10 QA Mistakes — Part 2

My last article was about top 10 QA mistakes. I did 6 of them because my daughter needed some help with the scissors. I want to finish the series giving you another 5. Oh, wait that’s 11! The title was just an eye-catcher.

TOP 10 QA Mistakes — catchy eh? — Part 1

Creating bug reports with not enough info

That’s a common QA mistake. Logs are not attached, no screenshots, no expected result, poorly described steps to reproduce. It’s your job to give as many details as you can, so the issue is easy to identify. Logs are a must have when the bug report is about backend related stuff. Screenshots for frontend and expected result as a part of the required coverage.

E2E testing, more like no E2E testing

Let’s say you have few big teams working together on one product. One team is doing the backend, the other one takes care of the front-end. There are QAs testing frontend and backend separately but there is no team designed to do integration testing. E2E testing is a whole team effort. You need to have both QA teams working together to identify the scenarios that should be covered, making sure all the dependencies between the systems are working as designed. There are few issues here:

• No team or team members assigned just to do integration testing,
• lack of documentation to get familiar with all the dependencies,
• bad communication between teams,
• only a few people know how this shit works (they are the ones that should create the documentation).

Fail to communicate with DEV team

Good communication is a key to success. Not only in IT world but in general. I’m not saying we should ask devs how this stuff should work, because this is why we have requirements, but you should talk to your devs to monitor the progress, to see if you are behind with writing your awesome test scenarios, or to coordinate with them the test data creation, making sure you know where to get the logs from. As my friend used to say “DEV folks are your friends, not an enemies” or maybe it was “QA is your friend, not an enemy?”, yea I believe it was the other way around because we were explaining our devs that we should work together. Anyways, yes we should cooperate on a daily basis.

Plannings, groomings, estimates, meetings

Imagine you are in one room with your whole team. Devs, QA, PM, PO, you name it. You are going through the user stories to see if you have enough info to start working on them. Your scrum master asks the common question:

— “Do you have everything you need?” — she or he said.

The dead silence hits the room

— “Ok, I’ll take it as a yes” — pissed scrum master replied.

This is usually what happens. Where are all the questions, clarifications? Where are the QA guys asking how we should test it? If we need any special access or data? And then we waste a whole bunch of time asking questions via e-mails where noting will ever get into the user stories description. We ask Devs, instead of asking PO and we end up having the story not how our PO imagined it’ll work. Please be active in those meetings, I know they are long and usually boring but you will save a ton of time later on.

We are not creating testing tools. By testers, for testers.

It might be just me but I would love to have QA management tools that aren’t retarded. A tool that is easy to add test scenarios, test automation without a shit ton of integrations, creating shitty test plans before you can add anything or you have to fill 40 fields to create a bug report. I don’t remember a good tool for Project and Test management combined. There is always something fucked up. I’ve tried Jira, GitHub, MTM, Axosoft, Asana, EasyQA, Rally, Product Studio and the whole bunch of other useless tools. They always have this little something that’s so annoying I quit using it.

So the conclusion is… I don’t have to money nor people to help me create an ultimate PM/QA management tool. But when I do…. oh man… just wait for it and see.

So, anyways, those are the mistakes I can see we make. Some of them are made by developers as well. Let’s try to be better in our field, not more expensive. The money will come along if you will be an expert in your field.