Your QA Team Tested Every Feature Before Release. You still had App Crashes and Bugs. Here's Why.

I spent 5 years as an engineer at Google working on a variety of mobile products, from the Android operating system to Google Maps. We had the world's smartest engineers and excellent quality practices, from a complete testing suite (unit, integration, & smoke) to an army of manual QA testers.

Yet we still shipped critical bugs to users. Check out any comment about the "Pixel phone alarm bug" or "Google Maps app crashes". Even after all of the quality checks, why do we still ship bugs? Well, there are a couple of challenges.

100% Test Coverage Isn't Enough

I've always aspired for 100% test coverage. We tried to prioritize it every quarter. The problem is that 100% unit test coverage doesn't consider the multitude of ways systems can interact with each other. And of course, it's infeasible to write the millions of integration tests required to cover every combination of system interactions. As a result, automated tests can never be a guarantee for software quality.

So we turn to manual QA. We find incredibly detail-oriented people and pair them with Project Managers who can ensure the golden user flows are tested every day, and new features are gated behind flags that QA testers enable to report early signs of bugs. They work really hard and find bugs before they reach users. But how many times have engineers had to wait days until a QA tester tests their feature before being able to launch it? Even worse, how many times have individual members of the team politicked their way into prioritizing their feature testing at the expense of more critical features. And the worst of all, how many times have you skipped QA because you had to get a launch or bug fix out…only to introduce more problems.

AI Coding Is Making the Problem Harder

There team is probably using some combination of Cursor, Windsurf, Devin, Claude Code, Lovable, Bolt, or Replit. They are pushing out features faster than before. Code quality is up thanks to all of the code review agents on your PRs. And the AI agents even write tests for you. Then why is your software still buggy?

Because none of these agents understand how your app actually works. They've never run it, so everything is being written theoretically. And will the same AI agent writing the tests truly write them independently of the features they wrote a second ago, especially if the context is the same? Now you have tests that are fitted to succeed on your feature code, creating noise against the authentic tests your engineers wrote years ago. You may be seeing the effects of this now, with bugs appearing in unexpected parts of your app, or the problem may snowball until the system is beyond repair.

Can Quality Be Solved

Quality is hard. Users are accessing your app on an exponentially growing array of devices (iPhone 15 on iOS 18, Samsung Galaxy S23 on Android 15), across hundreds of languages, and of course across different versions of your app. Is it even possible to guarantee that no configuration of your app on their device is bug free? The ideal solution would be a system that can ensure quality across every configuration, or at least where 90% of your users are, while being equally detail oriented for each user flow. It's impossible to achieve this with automated tests given limited engineering bandwidth, and impossible with manual QA because of finite staff and the real financial and time costs of onboarding new testers.

These are the problems we're trying to solve at QualGent. Our next post discusses what the ideal software QA solution looks like.