QA is not Dead: Why Even Big Tech Still Tests (and Why You Still Need a QA Process)

There’s a popular belief that companies like Google, Facebook, or Microsoft don’t do QA anymore. Developers write tests, everything is automated, and they ship thousands of times per year without anyone ‘testing’. But if you look beneath the surface, you’ll find that this isn’t actually the case.

Author: Andrian Budantsov, Hypersequent CEO and creator of QA Sphere

It’s true to say that many top tech companies don’t have traditional QA departments. Instead, they’ve built internal systems, automation frameworks, and tooling to make quality a shared responsibility.

Developers own the testing, but they’re supported by mature infrastructure that took years – and serious headcount – to build. And they still have people focused on quality, but just with different job titles such as SDET (Software Development Engineer in Test), Test Engineer, or Reliability Engineer.

Software bugs can have big consequences

Even then, flawed software still gets shipped. Late last year, Android 15 arrived complete with what KingofGeek described as a “treasure trove of bugs, glitches, and issues”, including random reboots and stability issues for the camera and Bluetooth connectivity.

These scenarios aren’t merely inconvenient for users; there are reputational and regulatory risks as well. An update to Instagram in February this year exposed users to disturbing and violent material, even those who’d adjusted controls to filter out graphic content, with Meta having to issue an apology.

Such incidents can have severe financial consequences too. Many owners of Meta Quest headsets were impacted shortly after Christmas 2024 by a software update that didn’t install properly, bricking the devices and forcing Meta to offer replacements and store credit to those affected.

In situations when quality is *really* expensive to get wrong – like with hardware – you can bet your bottom dollar that big tech companies have dedicated QA teams, even if they don’t use that specific term.

QA-by-developers only works for some products

There are instances when it makes sense for developers to handle testing. If you’re building a backend service – like an API that processes PDFs or handles data, for example – developer-driven testing may be appropriate. The developer can write clear functional tests, feed it inputs, verify outputs, and everything is under control.

But if you’re building a product that humans will use in real-world scenarios – in a browser, on a phone, on a slow connection, with unexpected and unpredictable behaviour – it’s a different world.

Now you need to see the product from multiple angles. You must think about usability, accessibility, edge cases, and real-world usage patterns. That’s not just code. That’s experience.

What this means for smaller teams and growing companies

Trying to copy the testing-by-developers model from big tech may not work unless you also have the same scale, budget, and internal tooling.

In reality, not every developer is great at writing high-quality functional tests. Nor should they have to be; they’re separate disciplines.

Sometimes it’s faster and cheaper to do semi-manual or exploratory testing than to automate everything. And automated tests aren’t free. They need maintenance. They break. They drift. Without ownership, they turn into tech debt.

Ensuring usability and accessibility is essential, and someone needs to take responsibility. At Google, entire teams focus on this. Startups must decide who’s in charge of this area.

QA is a process – and someone must take ownership

So smaller companies shouldn’t be asking themselves if they need to hire a QA. They should instead ask themselves if they have an adequate QA process in place.

Developers writing tests is great. It’s a baseline. But that alone doesn’t cover the full picture. You still need to know what’s been tested; what’s not been tested; what’s broken; and who is looking at the product from the end user’s perspective.

You need structured end-to-end testing. A human – whether it’s a QA, Project Manager, or even the founder – needs to look at the real thing.

You need a process that answers the questions of who owns quality; what’s covered; where are the gaps; and – crucially – what happens when something breaks?

A good QA process gives you visibility. It adds structure. It prevents surprises. It helps your team ship faster – and with more confidence.

You don’t need to copy how Google tests. You need something that works for your team.

About the Author

Andrian Budantsov is the CEO of Hypersequent and the creator of QA Sphere. With over two decades in software development, Andrian established a domain registration business before co-founding Readdle in 2007, serving as CTO until 2022. During his tenure, Readdle’s apps like Spark Mail garnered over 200m downloads and numerous awards. He was also CTO for Fluix, Readdle’s B2B division. In 2023, Andrian formed Hypersequent, developing advanced software testing tools with a commitment to quality, team building, and market-driven product development.