My main motivation to become a QA was a role model of a renaissance man. In the past being a QA meant knowing everything about different technologies and approaches as well as becoming the most oriented member of the team.
This article is a consolidation of my loose thoughts and observations across different companies as well as hundreds of interviews I’ve been taking part in.
Please don’t treat it as an overview of the whole QA world but as some kind of trend, I start to observe. I would discuss shortly different problems in a very shallow manner, although each of the points would be a part of a separate article in the future, so stay tuned.

Quality advocacy

Being QA to me means that you need to become a quality advocate, in short, that means the following things:

• Observe,
• Analyze,
• Conclude,

and the most important thing is to SPEAK UP, pretty often I have witnessed a situation when joining a new team where current QA members were concerned about things within the project but didn’t raise them because they weren’t feeling confident and knowledgeable enough, my advice here is trivial, be brave, you are the main source of raising red flags within the project, your input is the most important part of risk management.

Shallow wide became shallow narrow

The argument of not feeling knowledgeable enough to speak up leads us to another problem that I observe, back in the days QA had to know at least about the following areas:
General QA
Technologies used in the project
Domain knowledge both within the project and the area it was allocated in
DevOps

The phenomenon I observe more and more nowadays is that QA has little knowledge about QA itself as well as very shallow domain knowledge, more and more of them focus mainly on just testing the tickets and filling acceptance criteria than exploring and being curious. You don’t need to be an expert in each of these areas, it’s enough that you at least know that something exists and where to look for the answers, it’s not that much.

Automation != page object pattern

Narrowing the skills range, leads us to another point which is automation, this holy grail longed for every single company in the hope of solving all the problems related to quality, it’s not a mystery that it is not a magical remedy it’s just a supportive tool that lets QA find more critical issues, that are usually hidden underneath, but this is another topic, we will discuss in future, let’s focus on the clue. During many interviews when I ask candidates “how do you imagine a perfect automation environment” I get the answer “oh you mean page object pattern”. It bugs me a lot that so many QAs desperately try to become automation engineers without the basic knowledge about the things from point 2 about wide and shallow knowledge. In terms of automation, you don’t need to rely only on page object pattern, I will tell you a secret here, you can adjust individually your approach to every project you are working on, the goal is the overall quality and maintainability not sticking to the stiff rules.

Testing doesn’t mean quality

Sticking to the stiff rules and not being flexible causes another problem that everyone knows but not so many follow, testing itself does not mean quality, of course, you will find bugs and problems within the app itself, although in my opinion discovering a bug should be a last resort, your role is to help with processes and take an active part in discussions so you can prevent issues to happen. You can do it with this so popular shifting left approach where you are involved from the very beginning of feature creation by pointing out possible scenarios and problems.

Trying new things

Insanity is doing the same thing over and over again and expecting a different result this quote so often misattributed to Einstein is very relevant for our next point so trying new things. Dozens if not hundreds of QA on the market have the following tech stack in their portfolio, selenium+cucumber, I have even encountered companies that create dedicated teams that solve problems caused by selenium, dear colleagues there are plenty of frameworks and solutions that will solve your problems without workarounds, just reach for them. The second part is the famous cucumber, whenever I ask people ok, why do you use cucumber, the typical answer is so non-technical people can understand what is in the code. In the vast majority of cases when I ask, ok, so who in your team finds it useful there is no answer.

Treating QA as a jumpstart to the IT world

Many of the above problems I see, were caused by this one single cause, people treat QA as a jumpstart to becoming programmers, they think that QA is easy because “it’s just testing tickets” after that, they got comfortable, and forget about their goal to become a programmer, as a result, they end up in being neither good QA and programmer, this saddens me a lot because it’s causing some prejudice that QA, in general, is non-technical and non-useful team members.

Digging deeper

Dig deeper is something that is core of QA in general, being curious, asking questions, and understanding why, is your key and main goal that will let you become an indispensable and valuable team member as well as skillful QA. Let’s make QA great again :)