This talk takes as its starting point the Automotive Test Pyramid - a four-step framework for actually shifting left, not just talking about it. The steps are: classify the types of errors your team encounters, map those error types to the environments best suited to catch them, measure where bugs are actually being found versus where they should be, and make closing that gap part of how you work - baked into the definition of done.

Michael Fait, who authored the framework in his Medium article "A Guide to Shift-Left Testing: The Automotive Test Pyramid", joins Per Sigurdson to discuss what each step looks like in practice: where teams get stuck, where virtual environments fit in, and what you can realistically do this week without waiting for organizational change.

Michael Fait (Thoughtworks) talks about his automotive test pyramid framework with RemotiveLabs CEO Per Sigurdson and Emil Dautovic — covering shift-left testing, fast feedback loops, and the organizational blockers that keep teams finding bugs at the wrong stage.

‍

Measuring where bugs are found is the starting point

The insight at the heart of the framework is the measurement layer. For every bug reported, capture where it was found and what type of error it was — then compare that to where it should have been found. The gap is the shift-left opportunity: visible and concrete rather than theoretical.

Fait's practical starting point: go out on Monday and draw your actual pyramid. Map the value stream from "developer changes a line of code" to "it reaches a test fleet." Find out where bugs are actually being caught. Do not wait for the org chart to cooperate - just sketch it, bring it to people, and ask: " Does this look right? That question alone tends to start the right conversation.

‍

The blockers in automotive testing are organizational, not technical

The framework and Fait’s article identify three reasons shift left stalls in practice: lack of communication between development and system test teams, lack of trust in earlier testing stages, and no organizational incentive to improve the process after a bug is fixed.

The communication problem is structural. The standard link between a feature team and a system test team is an issue ticket, often weeks after the fact. Trust breaks down because teams rarely see what upstream testing actually covers. And when a bug is fixed, everyone moves to the next version - nobody has a mandate to stop and ask how to catch the same issue earlier next time.

Sigurdson pointed out what makes this particularly stubborn: the people best placed to fix the process are the ones most crushed by the delivery cycle. As Fait put it: after this release comes the next release. There is always an SOP. At some point, you just have to carve out the time — don't ask for permission, ask for forgiveness.

The structural fix: no closed issue without classifying the error type and the environment should have caught it. That small addition to how issues are closed is what builds the habit rather than relying on individual goodwill.

‍

A new environment is not shift left, reuse is

Adding a vECU environment does not mean you are shifting left. A new environment means new tests to write, new infrastructure to maintain, and new failure modes — without reducing anything downstream unless you deliberately replace scope. Run it in parallel with everything that already existed and you have added complexity, not removed it.

What changes the equation is reuse. When the same test frameworks, signal definitions, and topology descriptions run across all environments - from early virtual stages through to HIL and prototype vehicles - an early test and a late test are the same test at different fidelity levels. Moving a test left becomes a configuration decision rather than a rebuild.

Sigurdson also pushed back on a common assumption: a virtual integration environment does not need to be a perfect replica of the physical car. Organizations that start from that expectation over-invest in fidelity before establishing the basics. An environment that catches data interpretation errors, interface mismatches, and contract violations between ECUs is already doing significant work. Dirty sensor data, for instance, is far easier to inject virtually than on a physical bench. This is especially relevant as the industry moves from domain to zonal architectures - where functionality is spread across multiple nodes and end-to-end integration testing becomes the only way to validate that a feature works at all.

[nfobox]

How RemotiveLabs reuse from SIL to HIL

Achieving reuse across environments requires the vehicle topology to be described in code — so the same test logic runs consistently from early virtual stages through to physical hardware, with components substituted in as they become available.

With RemotiveTopology, teams describe ECUs, networks, and signal definitions in code. That same description drives virtual integration testing early, connects to bench hardware later, and scales as the project matures. Tests written at SIL are not thrown away at HIL - they run against the same topology at higher fidelity. Moving a test left is a configuration decision, not a rewrite.

See how RemotiveLabs approaches the full SIL to HIL workflow →

[/nfobox]

‍

Developer experience is the overlooked argument in automotive testing

Fait made a point that should take more space in shift-left conversations: slow feedback is not just a cost problem, it is a developer experience problem.

In most automotive organizations, a developer might wait weeks to learn whether a code change caused a problem. That delay has a real cognitive cost: context switching, large integration batches, harder root cause analysis. Shortening that cycle to hours or minutes for the test types that belong early changes what the work actually feels like. Fait's argument: making a complex embedded system do exactly what you want, with fast feedback, is more satisfying than most software work. Getting developer experience right is also how automotive becomes a more attractive industry for the next generation of engineers.

‍

‍

‍