TL;DR: Connected vehicles now ship with tens of millions of lines of code, OTA updates, and expanding app ecosystems, and Arxan Technologies says that shift is turning software quality into a safety issue as much as an engineering one. The control gap is no longer whether cars run apps, but whether testing, release governance, and rollback discipline can keep pace with software-defined vehicles.
NHIMG editorial — based on content published by Arxan Technologies: Why the Automotive Industry Deserves More Focus on Software Quality
By the numbers:
- Modern vehicles now ship with up to 100 million lines of software code, and that number is expected to climb in next-generation electric and autonomous vehicles.
- 26% of drivers have downloaded more than five connected-car apps, and 1 in 10 have downloaded more than ten.
Questions worth separating out
Q: How should teams test software-defined vehicles without relying on physical cars?
A: They should move toward automated validation that covers OTA updates, OS versions, display variants, and rollback behaviour inside CI/CD pipelines.
Q: Why does multi-app infotainment create more governance risk?
A: Because every additional app adds dependencies, integration points, and failure paths that can affect the whole in-vehicle experience.
Q: What are the signs that automotive software testing is not keeping up?
A: Common signs include reliance on physical head units for most validation, slow release cycles, limited coverage across vehicle variants, and defects that appear only after deployment.
Practitioner guidance
- Automate regression testing for OTA releases Build repeatable test coverage for every over-the-air update path, including compatibility checks across software versions, display configurations, and rollback scenarios.
- Test cross-app interactions as a platform control Validate how navigation, messaging, payments, media, and assistant features behave together, not just in isolation.
- Move validation into CI/CD pipelines Use automated flows and repeatable test environments so release decisions can be made at software speed instead of waiting for physical vehicle access.
What's in the full article
Arxan Technologies' full blog covers the operational detail this post intentionally leaves for the source:
- The specific testing workflows for Android Auto, Android Automotive, and Apple CarPlay environments.
- The continuous validation approach used to reduce dependency on physical vehicles and local head units.
- The Appium-based automation model for end-to-end in-vehicle testing across OS versions and display configurations.
👉 Read Arxan Technologies' analysis of software quality in connected vehicles →
Connected vehicles as app platforms: what does quality governance mean now?
Explore further
Software quality has become a governance control, not just a development metric. In connected vehicles, the quality problem affects safety, reliability, and user trust at the same time. That makes release assurance a cross-functional control issue for engineering, security, and operations. Practitioner conclusion: treat validation coverage as part of resilience governance, not a late-stage QA activity.
A question worth separating out:
Q: What should organisations do when software quality becomes a safety issue?
A: They should elevate quality assurance into resilience planning, with defined ownership, release gates, and traceable test coverage for every critical update path. Safety-relevant software cannot depend on informal sign-off. The program needs measurable assurance that each release has been exercised against the environments it will actually encounter.
👉 Read our full editorial: Software quality is now a safety control in connected vehicles