In the dynamic domain of embedded automotive software, achieving high quality, safety, and performance is non-negotiable. This is becoming even more important when looking at topics like Software-Defined Vehicles. For over 20 years, our company has enabled automotive OEMs and suppliers to start testing as early as possible in the development process. In the last years, this has been also called “shift-left testing.” We recently had a presentation on our BTC Software Quality Summit in Chennai/India which was titled „Fail early, fail cheap“.
In this article, we’ll explore why early testing is crucial, the benefits it offers, and the pitfalls of waiting to test your software later.
What is Shift-Left Testing?
Shift-left testing is the practice of integrating testing activities as early as possible in the software development lifecycle. Rather than saving all tests for later stages—where defects can be much more expensive and complex to resolve—shift-left encourages continuous testing from the very beginning.
The Benefits of Early Testing
Finding and fixing defects early in the development process is significantly less expensive than addressing issues during or after integration. The earlier a bug is caught, the lower its impact on the overall project, reducing both time and financial costs. Leading consulting and engineering companies, which have insight into many different companies, also address the topic, for example in this article.
How to shift left?
Let’s take a look at what early testing means. Often, testing is done directly on the HIL, which brings some challenges. In this scenario, bugs are difficult to locate because you can only observe the interfaces of an integrated system, and this is further complicated when you have to trace back through the entire V-cycle to fix the bug.
A first “Shift-Left” step would be a Digital Twin (integrated SIL). This scalable solution is better and cheaper because no hardware is involved yet. But even here, the system is already integrated, so de-bugging can still be complicated.
It would be better to go straight to SIL in unit testing. Here, the individual units are not yet integrated and can be tested separately. This makes simulation and error analysis much faster, which should result in saving time and money. The subsequent integration test then focuses exclusively on the integration.
The disadvantage here, however, is that the code must still be brought into a “compiler ready” state and then compiled before a test can be executed. However, if you are developing C code directly in your project, you cannot move any further to the left.
For model-based software development (MBD), testing should be moved to MIL, as the code is generated from the model and bugs will eventually need to be fixed in the model anyway. The advantage is that testers can functionally test the model very early, even before a configuration for code generation exists or any code is generated and compiled.
The last “Shift-Left” step that can be achieved with MBD is Test Driven Development, where the developer tests directly in the model during development. Test cases can now be defined right at the beginning, allowing us to verify the expected behavior of our development efforts from the very first step.
By continuously testing throughout development, the developer and tester receive rapid feedback and can detect critical issues as early as possible. This constant checkup not only improves code quality but also ensures that the final product is robust and reliable—a necessity for the new world of Software-Defined Vehicles where your units also must be robust against changes in its environment.
This also means that when defects are caught early, rework is minimized. This streamlined process leads to shorter development cycles and a faster route to market. Be that as it may, the truth is that the processes for developing software must be adapted accordingly. We were too slow in the past and market pressure has forced and is forcing us to become much faster.
You can find more information about testing early on MIL in the following blog article.
What might hold us back?
We regularly hear that we should reach „China-speed“! However, we are trapped in our previous patterns of experience, which have shown us that development cycles that are too fast also increase the number of undetected errors. We are challenged to shed these beliefs and find ways to become faster while maintaining quality. The competitors will not wait.
This requires a change in companies’ culture. And since we know that „culture eats change for breakfast“, this must be supported by all those involved out of inner conviction, from management to employees. Early testing fosters, and even, requires, a culture of collaboration between developers, testers, and other stakeholders: Leave the silos. When testing is integrated from the start, everyone shares responsibility for quality, leading to improved communication and a more cohesive development process. As an add-on, this will help remove the issue of finding defects too late when those were already completely propagated through multiple components, thus complicating the debugging process.
Please, don’t get me wrong. Testing on higher levels will not become obsolete but should be faster, less complex, and less difficult if the software units have already been extensively and comprehensively tested. Also finding defects located in units later in the integration or system test will force you to go back to the units, fix it and repeat all the previous steps to ensure the fix did not break something else. Or worse yet, defects will get overlooked and will show up after the product is in production.
How to implement a Shift-Left Testing approach
- Integrate Testing Throughout the Development Lifecycle: Include unit tests, integration tests, and code reviews from the very beginning and implement tools in your development process that will support this approach.
- Leverage Automated Testing: Having a Test-Driven Development Approach established will also enable automation at an early stage to identify regressions and reduce the manual effort required to maintain test coverage.
- Adopt Continuous Integration and Delivery (CI/CD): A robust CI/CD pipeline ensures that every code change is automatically tested, providing immediate feedback and automatically triggering automated test steps.
- Change your mindset: Encourage and force close collaboration between developers, testers, and other stakeholders to ensure that quality is a shared responsibility. This must include the left side of the V-cycle in order to get their homework done. Implementation and testing can only be as good as the requirements are.
- Invest in Training: Equip your team with the tools and knowledge to embrace early testing. I often see in customer meetings that even experienced users are not aware of all features our test tool provides. Things that they have wanted to use for a long time and just didn’t know that they were already there.
Conclusion
In the automotive embedded software, early testing isn’t just a best practice—it’s a necessity. Embracing a shift-left approach means catching defects early, reducing costs, and delivering more reliable and safer products. Delaying testing can lead to increased complexity, higher costs, and compromised safety, while integrating testing into every phase of development paves the way for faster time-to-market and a more agile, collaborative workflow.
New challenges, such as the development of a software-defined vehicle, require a rethink. Unlike in the past, software components are subject to a much longer service life and change period. Nowadays, customers expect to receive regular software updates after purchase and want to benefit from new features and improvements.
As automotive systems continue to evolve in complexity, the shift-left strategy will remain an important factor in maintaining high standards of quality and safety. By prioritizing early testing, companies will not only mitigate risks, but will also drive innovation, ensuring that they stay ahead in an ever-competitive market.
