6 QA Mistakes and How to Avoid Them

1. Forget the bigger picture

When one starts as a junior tester and has the excitement of a well-rested golden retriever puppy, it is inevitable to sometimes forget the bigger picture. This is when a junior fills my Jira board with improvements, misaligned pixels, icons which are slightly off-center and missing semicolons two weeks before I need to submit a final release candidate. It is also the quickest way to see me hyperventilating. What I need at this stage is reassurance that the major features are working, nothing is broken, crashes are a distant memory, and the application is user-friendly and easily accessible — not grammar check and UI perfection.

The best thing about new testers is their endless eagerness to find as many bugs as possible and prove themselves valuable. However, the worst thing about new testers is their endless eagerness to find as many bugs…you know how this ends. Sometimes they tend to focus on minor small details at the worst possible moments. Prioritizing is something that is learned and with time one starts understanding that there is a right time to file trivials and an approaching scary deadline is probably not that time.

2. Add issues based on your feelings

I think that this icon will look better if it was orange instead of blue. I feel that this logic is a bit hard to comprehend so I feel that we need to add at least four more pop-ups. No! Junior testers do not get to make suggestions. Is that too harsh? Okay, let me try again, junior testers get to make suggestions at the right time to the right people.

When we first start developing a feature or a module at the beginning of the projects, usually all suggestions are welcomed. We get to think creatively because we need to think about all possible edge cases and user scenarios in order to write detailed and full test cases. This is when the solutions architects or designers are most prone to listen to suggestions and take our ideas into consideration.

If you really believe that your input is valuable and you have done your research, then go ahead and dazzle us. However if our workflows, renderings, and proposals are already approved, implemented and tested, it is usually too late to change things no matter how great your ideas might be. And never ever file bugs based just on your own preferences.

3. Forget the existence of your designer

Speaking of renderings, workflows, and issues about them, there is no faster way to enemy-fy your designer than going over their head and adding improvement on their work or even worse — bugs about their designs. I love my designers and I very much trust in their competence that if they have designed a feature in one way, then they have a very good reason to back that up. I know how much effort they put into researching different ideas and I know that they are usually in very close collaboration with the client and are probably more aware of the client’s UI demands than I am.

If I have to be completely honest, I still sometimes make this mistake and in the heat of the moment, decide to add something to a feature without consulting my designer first. I do it with the best intention of improving something but my best intention means little if I am disrupting the agreed process and adding an unexpected delay.

4. Piss off your devs

Ahhhh, devs can be intimidating, devs can be irritating, devs can be arrogant and grumpy. But devs are always your best friend, always! So you try your best and establish a trusting relationship. You go and you grind until they tolerate you, dare I say even like you. Because happy devs = happy QAs. Even if you have to hear 1,000 times “it’s not a bug, it’s a feature”, you bite your tongue and you persevere. If you don’t believe something your dev tells you, you can go to a senior one and ask for a second opinion. But ideally, it is best if you maintain a trusting partnership. You need to trust their experience and then they will trust your competence. It is a beautiful symbiosis but a fragile one.

The devs need to trust that you have their back, that even though you want to break their code, you do it with the best intention and for the greater good. And you need to trust that sometimes, very rarely, a bug is indeed a feature. 🙂

The fastest way to piss off a dev btw is when you test a half-done module and you add a bunch of bugs about things that aren’t even implemented yet. Give them time, don’t rush them and try to hold on your enthusiasm until they are done with their part and your part can start.

5. Assume your are too good for documentation

Ahhh, that is me in a nutshell. The most tedious task for me is writing test cases or modifying the existing ones with new edge scenarios and information I have unveiled during my testing. When you gather some momentum and testing confidence, you start to omit the basics. You find yourself too pressured by time to bother following a checklist template so you do it by memory without a trace of your results. You are so sure in your ability that you forget that every testing needs to have a visible footprint. Especially if you are handling a project all by yourself and know every little detail about it, you forget the need to document and that can so easily come back and bite you in the tushie.

I am guilty of that and for the longest time skipped some steps in order to have more time for other tasks. But in some instances, your honest word doesn’t matter unless you have a document to back you up. If you say for example that something is a regression because it used to work flawlessly before and then someone asks you to show them proof of that and you can’t, it looks unprofessional. You never know when you will be switched to another project or someone else needs to take over your work and this someone else will be totally lost unless you have done your paper part.

6. Not doing the groundwork

Let’s say your project is a mobile application supported on Android and iOS. A junior tester is checking an Android phone and sees a crash. Junior is ecstatic, a crash is a big deal so they hurry to add it to Jira as soon as possible and raise the alarm. What they forget is all the other steps one needs to do before adding a bug, especially an important one. There is a bit of groundwork before adding an issue. First thing is to check the filing system, whatever it may be, for duplicates. Nobody likes duplicates and they make you look sloppy! The second is to check in a few more places to see if that issue is device-specific, platform-specific or a general one. So they better check an Android tablet and then an iOS device etc. It would also be helpful to gather some logs so that the dev can save up some time to try to reproduce and quickly check the logs instead. It is also useful to see how often you can reproduce the issue, does it happen every time or a bit more randomly. Isolate the exact steps for the issue and also check maybe previous builds and versions to see whether it is a newly introduced regression or it has been there and missed all along.

These mistakes are a common part of a QA’s journey and are a natural step to the learning process. Now that I have passed this precious cargo of a legacy along the way, please reach out if you have any questions, or if there are even more unforgivable QA sins which I have missed.

P.S. Need some help testing your TV Apps? We offer OTT testing as a service, including basic and premium OTT features, pre-defined and bespoke test cases, as well as device manufacturer certification checklists and app validation. Find out more and reach out here.