Top 3 Mistakes Companies Make in QA Decisions

I actively engage in QA consulting in large corporations and small startups and have identified the three most common mistakes companies make in QA decisions during QA audits.

?? What is a QA Audit? It's an independent assessment by a QA expert on the current state of a QA department: processes, employee qualifications, task execution quality, and most importantly - conveying the final value of "quality assurance" to the company's goals. In simple terms - whether we are wasting money or not.

You might ask, "Why do we need QA within the company?" Unfortunately, not every QA has enough experience and exposure to conduct a quality QA Audit. In some cases, on the contrary, a QA might be interested in not disclosing the truth - as they would then lose their job and the ability to simulate active work (and yes, that happens).

I recommend this reading for QA specialists as well as company management who needs quality assurance.

?? ERROR №1: Hiring QA without QA expertise

It turns out that companies often hire QA without understanding anything, specifically:

• What QA should do - if it’s somewhat clear what to do with automated tests, manual testing remains in the dark among typically super technical business owners.
• How to track QA's work - if there is no understanding of what QA should be doing, then there’s certainly no idea how to track the dynamics of this "something."
• How to build QA processes - a mystery for most development participants, and often for the QAs themselves.

Why? To answer this question, looking at?when?QA is typically hired is enough. Usually, it happens when a startup has successfully taken off and there’s more than enough money, the user base is continuously growing. The owners are trying to cover all bases - hiring “cheap” QA, analysts, and PM just in case.

Over time, depending on the owner’s involvement, their attention is drawn to the QA department, which is spending a considerable amount of money, and critical bugs keep growing. Yes, there’s a chance that the company got lucky and those first QAs turn out to be great specialists, but honestly, they are generally few, and startups in the beginning often save money (or are not aware of the real rates) and hire QAs with no experience in building anything from scratch. And maybe, QA would like to build something cool, but lacks the experience, and then either:

• starts shouting “urgently looking for a QA expert,”
• or quickly sees the benefit and will ask for more money for the lack of results.

As an independent QA expert, I have seen both cases and can estimate how much money was wasted.

Why? Errors at the start of a project are the most expensive - choosing the wrong technologies, and purchasing insanely expensive QA tools. And frankly, often a QA project is not yet needed and for a long time during the “testing hypotheses” stage, they can survive on a couple of scripts embedded in the pipeline. But which QA would say that? I hope most QA engineers, but more often already hired QA will start pulling tasks out of thin air rather than honestly admitting that it's too early to start automation from scratch.

Call to action - the main idea here:

• Companies - reach out to QA experts who work on results for hiring a QA department from scratch (if you need one at this stage at all). You will save money and time. You can write to me (Alex Pshe) for QA advise.
• QA specialists - be QA experts who can help the company at an early stage not to waste money but to build testing that matches the current goals of the product. We discuss in detail the steps to build testing from scratch in NoBugs.

?? ERROR №2: Process gaps

Imagine - your QA department is bustling, testing features daily, running regressions, and maintaining checklists. It would seem - where could bugs come from? But users keep complaining and complaining. Bugs are growing and the boss drips daily on the brain “Where’s the result?”, already ready to buy any new QA tool (that’s how they make their money, yes) just to cover this hole with money.

What’s the problem? The most popular “process gaps”:

• No connection with users/customers (or the Customer Support department). That is, literally, users walk through different user scenarios than those written in the QA checklists. Seems unreal? But no, many companies have a gap between the feedback loop, no open bug tracker, or another way to see real feedback.
• No connection between QA Manual and QA Auto. That is, literally, QA Manual is not aware of what’s in the regression, and why believe the code - so I will go and check the SAME thing that has already been checked by automated tests, and yet time is limited, so naturally, there is no time left for all other corner cases.
• No connection between the development flow and the QA flow. That is, literally, we skip testing certain versions/builds of the product because initially, automated tests were built as something separate from the development and launching processes at the whim of QA. But there are heaps of automated tests and such, but different pipelines.
• No testing artifacts. That is, literally, all checklists and test documentation are stored in the minds of QAs. Often, this problem is attempted to be solved by purchasing TMS (spoiler, it does NOT solve the problem in 90% of cases). Here more likely help: mandatory processes and culture. Yes, unfortunately, many QAs consciously create a bus factor for themselves, feeling safer by storing important information for the company right in their heads.

Did you feel a familiar pain in your heart?

Well, you are not alone.

How to solve such problems?

Companies - hire QA experts - at least one in a leading role.

QA experts - look at the situation around beyond one automated test/test case, analyze, try to map all processes and make sure you understand all peripheral processes with other areas.

?? ERROR №3: Attempting to “buy quality”

Probably, you have often been surprised by the number of QA tools on the market - as of 2023, the QA tools market is estimated at $51.8 billion. One might wonder - why do we need so many tools and who buys them?

So, bulky QA tools are most successfully sold as a “miracle pill” to management, which hopes to patch quality gaps by purchasing the next TMS or all-in-one solution with charts showing that everything is green.

How many expense sheets I’ve seen for tens of thousands of dollars for a solution that only brought additional costs for onboarding and then offboarding (when everyone realized that instead of easing, it just added hassle), to eventually return the QA department to the starting point.

Let’s be honest - practice shows that the simpler the solution, the better.

How best to “try on” a solution before buying?

1. Try to find any manual process that covers the problem. For example, sending the testing status in one channel or forming test cases in flexible systems like Notion or Google Doc.
2. Live with a manual process for a while to gather all the bumps - what’s convenient, what’s not, what are the features. Here you will find working formats suitable for different tasks, understand what you were missing before.
3. Now that you have a time-tested manual process, you can think about optimization and look towards existing or custom solutions to increase efficiency.

And how does it happen in reality? In reality, tool managers come, who are informed about how to sell to other managers - with big charts, fairy tales about green dashboards, and a list of companies with successful cases. And then it turns out that your manual process can’t fit into the tool’s case at all and a separate question - who, when, and how will find out that we don’t need the tool at all.

Of course, in practice, there are even more mistakes, but for now, we move on and continue to accumulate our box of stories to tell you.