A software change can satisfy the requirement it was created to fix and still create a new vehicle-level risk.
That is what made a 2025 Volvo recall particularly instructive. The U.S. National Highway Traffic Safety Administration warned owners of certain plug-in hybrid and battery-electric models about a potential loss of braking after an earlier over-the-air recall remedy. The first software update had been issued to address rear-view-camera failures; NHTSA said the later braking defect originated from that remedy.
The lesson is bigger than one recall. In a software-defined vehicle, a change does not necessarily remain confined to the requirement that triggered it. Vehicle behavior emerges through software, ECUs, networks, hardware configurations and other functions operating together—which is why modern V&V increasingly uses software, system, SIL/MIL/HIL and vehicle-level testing rather than relying on a single test layer.
For OEMs and Tier 1 suppliers, that changes the quality question.
The question is no longer simply: “Did this release pass verification?”
A more useful question is: “Do we have enough connected evidence to trust what this change will do in the vehicle?”
Verification, validation and assurance answer different questions
Verification asks whether the implementation satisfies specified requirements. Validation asks whether the integrated system is fit for its intended use and behaves appropriately in the conditions for which it is intended. Assurance asks whether the processes and evidence supporting those conclusions are controlled, traceable, and trustworthy.
They are related questions. They are not interchangeable.
Automotive SPICE 4.0 reflects that distinction structurally: software verification is addressed through software engineering processes including SWE.4, SWE.5 and SWE.6. Validation is represented separately by VAL.1; and Quality Assurance by SUP.1.
That matters because passing a test is not the same as understanding the full effect of a change.
A test provides evidence for the conditions, inputs, and expected outcomes it covers. But a software change that behaves correctly at component level can encounter different interactions after integration, across another configuration or under an operating condition outside the original regression scope. SIL, HIL and vehicle testing exist in part because different levels expose different classes of behavior.
The answer, therefore, is not simply more tests.
It is better continuity between what changed, what could be affected, what was tested, what was not tested, what failed and why the remaining risk is acceptable for release.
The assurance gap often sits between test levels
Most mature automotive programs already generate substantial test evidence.
Software-level verification can expose logic and interface problems early. SIL can increase test speed before target hardware is available. HIL introduces ECU, network and hardware interaction. System and vehicle validation exposes behavior that only emerges as functions operate together. Current automotive V&V strategies increasingly combine these environments with automation and continuous-testing pipelines.
But each level can be successful individually while assumptions between the levels remain insufficiently challenged.
Release confidence comes from connecting them.
This becomes particularly important when software continues changing after SOP. UN Regulation No. 156 establishes requirements for vehicle software updates and Software Update Management Systems, making disciplined, controlled software change a lifecycle concern rather than only a development-phase activity.
Five signals your V&V system may be generating test evidence without release confidence
These are not simply testing problems. They are release-confidence problems.
From test execution to continuous release confidence
A connected model makes evidence flow with the engineering work:
Requirement → Change Impact → Verification → Integration → Validation → Assurance → Release Decision
The important difference is continuity.
Traceability, coverage, defects, deviations and test results should not have to be assembled only when a customer review, assessment or release gate approaches. This echoes the continuous-quality principle in Acsia’s preceding QA article: evidence becomes more valuable when it stays visible as the program changes.
It also makes shift-left more meaningful. Virtual environments and automation can move verification earlier and increase execution frequency, while HIL and vehicle-level capacity can focus on the conditions where physical integration adds the most assurance.
How Acsia approaches connected V&V and assurance
Acsia approaches automotive V&V from software through system and vehicle-level testing across digital cockpit, telematics, EV, ADAS and cloud-connected functions. Its capabilities include SIL/MIL/HIL, continuous testing, automated regression and an in-house configurable automation framework, TITAN.
The QA layer adds the other half of the picture: work-product and evidence reviews, traceability, process adherence, non-conformance governance and milestone readiness, within an engineering environment that also spans Automotive SPICE, functional safety and cybersecurity.
The objective is not a longer test list.
It is to connect engineering depth, V&V evidence and quality assurance closely enough that a passing result can support a defensible release decision.
Because for automotive software, “it passed” should be the beginning of the release decision—not the end of it.
If your program is generating substantial test results but still encountering integration surprises, uncertain regression scope, traceability gaps or late release concerns, the issue may not be test execution.
It may be the connection between verification, validation and assurance.
