Being a QA Sucks - Sometimes

I am a decade-old QA turned consultant, and I believe I have seen most — if not all—of the ups and downs of software testing. One thing I have observed in almost every engagement is that QAs are treated as second-class citizens. Except for one particular experience, everywhere I worked, QAs were undervalued.

Despite the fact that QAs are key contributors in shaping product quality, they are often ignored.

Test automation is considered the primary selling point of QA and is practiced by most teams, yet it remains one of the lowest-priority items. Especially for stakeholders, automation is no ROI product and often perceived as an "IT problem" rather than a product quality concern.

A big part of this perception problem comes from how we historically approached automation.

Automation Framework - The term

The very first thing which damaged our reputation is term "Automation Framework", a term which often used by QAs to sound technical but it does not do any good except introducing negativity.

"Automation framework" is one of those terms from the software industry that I absolutely hate.

First, let's stop calling automated tests an automation framework. Be precise. Call them automated UI tests, automated API tests, or better, end-to-end UI tests.

History

A decade ago, most of us in QA were busy building automation frameworks using Selenium, and most of us failed miserably. I know this is history, but it matters, because we lost credibility right at the beginning.

We never achieved the ROI we promised to developers, managers, clients, and stakeholders. Our automated tests often ended on a sour note: they were flaky, failed at crucial times, were expensive to maintain, and most importantly, they rarely discovered real defects.

This pattern continued for years, slowly damaging our reputation.

QAs could not regain the lost trust. Stakeholders kept asking for more coverage, and we kept adding more tests and more people to automation.

The automation journey started on a sour note, and it never really got the appreciation it deserved. We are still on the same boat today. The tools have changed — Selenium became Playwright — but the mindset has not.

We are still chasing quantity, not quality.

Mindset

There is one more mistake we have repeated for years: believing that QA is the sole owner of automation. We never involved developers in test automation -- perhaps, many of us believed it will kill our role.

We maintained a silos. This mindset needs a change, no more secrets. Developers should consume test automation. Developers should contribute to it. Automation should not belong to QA alone. It should belong to the team.

---

Now it is high time for QAs to take this seriously.

We need to make a better promise to developers, stakeholders, and managers: we are not going to chase quantity.

That means we may be slower in adding new tests, and that is fine. What matters is quality.

Our focus should be simple: if a test fails, it should fail for a genuine reason.

Our tests should run on every meaningful code change. If needed, we should learn and practice DevOps skills to onboard our tests into CI pipelines.

Let's encourage everyone on the team to consume and contribute to test automation. Let's make it a shared engineering language. That's the only way to change perception.

QA is a difficult role but when practiced right, it earns only appreciation. Nothing else.