10.06.2025

Why Software Defects Keep Slipping Through – The Core Problems Behind OEM QA Failures

After millions of recalled vehicles, costly class-action lawsuits, and increasingly vocal customer complaints, one question remains: why does this keep happening?

Automakers aren't blind to the challenges. They’ve invested in software teams, hired renowned experts from other industry segments, and launched internal QA platforms. Yet despite the effort, infotainment bugs, integration issues, and system crashes continue to ship in production vehicles.

There are several reasons why.

OEMs Remain Reactive, Not Proactive

The majority of OEMs still operate under a firefighting mindset when it comes to software quality. Quality analysis often begins only after the product is already in trouble: during final testing, at the tail end of the development cycle, or worse, once issues have surfaced in the hands of customers.

In reactive QA approach, issues are discovered too late, often by customers

This reactive approach leads to:

Late-stage bug discovery, when fixes are costlier and riskier.
Ad hoc task forces formed to triage field complaints.
Piecemeal validation, with limited insight into long-term stability or rare issue patterns.

As described in our recent blog post, what’s needed instead is a proactive quality strategy. That means embedding issue discovery throughout the development lifecycle, not just at the end. It means leveraging real-time behavior analytics, AI-assisted defect detection, and robust integration testing before vehicles hit the road.

Unfortunately, most OEM QA teams aren’t set up for this shift. They rely on waterfall-era processes, test benches that simulate too little of the real world, and organizational structures where infotainment validation sits in a silo, disconnected from telematics, cluster, or ADAS.

100% functionality doesn’t mean long-term stability

Too often, OEMs underestimate how software defects can take weeks or even months of continuous use before they surface. Traditional quality assurance methods fall short when it comes to uncovering these slow-burning issues:

Automated functional testing checks if features work once during a test, but says nothing about how they behave over time.
Manual testing demands large teams, yet the testing windows are typically too short to expose long-term stability issues. And since the process is human-driven, critical problems can slip through the cracks.
On-road fleet trials, once designed to test mechanical durability, are now also used to test software. However, these trials often don’t run long enough to capture hidden software defects, or collect enough data to help engineers understand the problems.

What’s the common problem across all these methods? They may indicate that something went wrong, like “the feature no longer works” or “the system crashed”, but they rarely provide the why. A vague field report saying “infotainment crashed” doesn’t help engineers pinpoint the root cause, let alone fix it.

“That’s a Tier1 problem” is a dangerously outdated mindset

We still hear it far too often. It’s a holdover from traditional development models where OEMs sourced subsystems as black boxes from Tier 1 suppliers: defining requirements, receiving deliverables, and integrating them with limited visibility into how those components were built or tested.

That model simply doesn’t work for complex, software-intensive domains like infotainment. Both OEMs and Tier 1s are navigating unfamiliar territory—systems like Android Automotive OS are still relatively new, and neither side has deep-rooted domain expertise.

The result? OEMs often fail to enforce stringent quality requirements, while Tier 1s deliver under-tested software because robust QA was never expected of them. On paper, Tier 1 may be contractually responsible, but when infotainment systems fail in the real world, it’s the OEM’s brand that takes the hit. Customers don’t blame the invisible supplier; they blame the name on the steering wheel.

In-House Tools Aren’t Closing the Gap

Despite how they may think, many OEMs lack the domain expertise to build effective QA systems themselves.

The GM case discussed in Chapter 4 is a notable example. Despite public claims of a cutting-edge, AI-driven in-house quality platform, the company is still sitting on a long and growing list of acknowledged infotainment defects. The disconnect between the promise of advanced internal QA and the reality of unresolved field issues suggests that the tools — no matter how smart — aren’t enough on their own.

Why is that?

Software quality is not a generic engineering problem; it demands deep, product-specific expertise.
In-house teams often lack the cross-functional visibility needed to diagnose root causes across vendor-supplied code and in-house components. OEMs are used to working in silos: a working model that does not encourage cross-team collaboration.
Android alone is a wildly complex SW system developed by Google, not by OEMs, and their understanding of its inner workings is limited.
AI models can only perform as well as the data they’re trained on—and in the case of infotainment systems, real-world behavioral complexity is notoriously difficult to model without domain-specific knowledge.

OEMs are car companies first, software companies second. While some are trying to pivot into becoming software-first organizations, building a world-class QA function from scratch is a years-long journey — and customer expectations won’t wait.

Takeaway:

Despite major investments and growing awareness, infotainment software issues continue to reach customers. This chapter outlined the systemic reasons why:

Quality assurance is still reactive. Many OEMs only begin serious QA efforts when defects have already reached the field—leading to rushed patches and high-cost fixes.
Traditional testing misses long-term problems. Functional and manual testing often validate only short-term performance, not how systems behave over weeks or months of real use.
OEM–Tier1 dynamics are misaligned. Infotainment systems require deep collaboration and shared responsibility, but too many Tier1 relationships still operate like it’s 2005.
Domain expertise is lacking. OEMs’ in-house QA tools often can’t address the complexity of infotainment systems like Android Automotive OS—resulting in persistent, unresolved bugs.

Until these structural issues are addressed, OEMs will continue to struggle with missed defects, delayed resolutions, and reputational damage.

In the final chapter of this series, we’ll summarize the most important lessons learned so far and explore how OEMs can turn software quality into a competitive advantage moving forward.

Other articles in this series: