Challenges in Automotive Testing

Even the highest quality organizations have tradeoffs when it comes to their testing coverage.

In Japan, Europe, and the United States, automotive manufacturers are aiming to enhance automotive functions by using software; in Japan in particular, Toyota, Nissan, Honda, Mazda, and Subaru are all adding endless amounts of software to their vehicles in the form of convenience and safety features. In the automotive industry, many companies are original equipment manufacturers (OEM), meaning they make most (if not all) of their automotive parts in-house. While, Sony, Panasonic, and other electronic manufacturing companies are researching ways to increase their sales and profit, automotive companies’ business is growing. According to statista.com, in 2016, the sales value of the automotive software market in Japan was valued at ¥525 billion Japanese yen ($4.8 billion USD); it is expected to reach ¥747.5 billion Japanese yen ($6.8 billion USD) in 2020 and ¥995 billion Japanese yen ($9 billion USD) by 2030. Japanese automotive brands have a history of being the most reliable vehicles; thus, they will want to ensure their software is reliable as well.

According to J.D. Power’s 2019 U.S. Vehicle Dependability Study, which ranks brands based on problems per 100 vehicles, two out of the top three brands are Japanese: Lexus is number 1 and Toyota is number 3. Infiniti and Subaru make it above the industry average and Nissan is just 1 ranking below said average.

The Tradeoffs of Coverage and Risk

Even the highest quality organizations have tradeoffs. As old as Software Testing, automotive Software Testing has the same issues. Technology aside, companies have to balance coverage and risk with cost and time. High risk needs more testing, more people, more time, and more coverage. Less risk often means less testing, less time, and less coverage. No one wants to make these tradeoffs-especially in a safety-critical product. In a regulated industry, these tradeoffs are often standardized levels demanded for regulatory compliance.

With shift-left, more Continuous Delivery (CD), and modern development techniques like test-driven development (TDD),  there is more unit testing and more meaningful measures of unit test code coverage. The tradeoff may become coverage at what level. Test coverage at the unit level, API or service level, or testing at the UI level. The following is an example of how a Japanese software company balances coverage and risk on an automotive project.

The level of quality demanded varies from project to project. Testing car navigation may require a different level of quality than an electronic control unit (ECU) because car navigation does not have the direct power to kill people.

On the other hand, ECU testing—a system that can kill—requires a higher quality, such as 100% C1 (code-level Branch Coverage) coverage rate, sometimes requiring MC/DC coverage rate. The aforementioned testing terms form a basic idea and methodology toward quality assurance for automotive software.

In one automotive project, we had to balance and think about the size of software and the relationship between ECU and the car navigation system (see Figure below).

· Software size of car navigation = Huge (using Linux, Car Play, Android Auto)

· Software size of ECU = Small (Using automotive specific OS or non-OS)

Based on risk:

· It is okay to cover 100% coverage testing with small ECU software.

· It may be okay to cover less than 20% code-level coverage testing with huge car navigation software.

Figure – Relationship between ECU and the car’s navigation system

Treated separately, it is okay to not communicate between ECU and car navigation. When the ECU communicates too much with car navigation, there could be critical quality problems. But, automotive software is becoming increasingly complicated every year.

And the size of data communication between the ECU and the car navigation is increasing. An ECU may use Open Source Software (OSS). The ECU may also use virtualized software. The ECU may communicate to the internet or cloud directory. ECU software may be updated by internet.

By themselves, the pieces can be tested. The integration and many workflow paths can be very complicated and leave data under various loads—calling for different testing than code coverage.

The Other Side of the Equation: More People, More Time

We are test engineers. We need to prepare ourselves to strategize such kind of complicated automotive Software Testing tradeoffs between coverage and risk. Currently, there are too many developers compared to testers working for automotive system software.

I worked at Microsoft’s headquarters in Seattle. At that time on my team, more than 300 development and testing engineers worked together to develop Windows OS.

From my experience, I can say the team ratio is that there are many more developers compared to testers working on automotive software than the entirety of the Windows OS.

Interestingly, some companies are afraid to increase the size of the software test teams.

I believe that software engineers for the automotive industry need to prepare and improve their effectiveness and efficiency for production. Both developer-level unit testing skills are needed as well as integration level testing. Test Automation is key to increase productivity.

Summary

How much testing is enough? This is a question as old as software itself. How much gets covered in the test effort is a balance of risk, cost, and schedule. These days, with shift-left mindset of more developer testing, how much test coverage happens at each level is the new question.

To achieve the level of quality and testing needed for safety-critical applications, highly skilled engineers are needed for both developer level testing and all aspects of Test Automation.

Juichi Takahashi
Juichi Takahashi is CEO of LogiGear Japan. Prior to LogiGear, Dr. Takahashi held engineering and technical leadership positions in software testing and QA for prominent software/IT and product companies including Microsoft, SAP, and Sony. Throughout his career, he has gained extensive experience in testing and quality engineering. Dr. Takahashi is the author of the top-selling testing book in Japan, “Software Testing for Beginners.”

The Related Post

How lagging automotive design principles adversely affect final products. Cars are integrating more and more software with every model year. The ginormous screen introduced by Tesla in their flagship Model S a few years ago was seemingly unrivaled at the time. Nowadays, screens of this size are not only commonplace in vehicles such as the ...
An automation framework is a way to organize your code in meaningful manner so that any person who is working with you can understand what each file contains. Automation frameworks differ based on how you organize your code – it can be organized based on your data, so that any person who wants to use ...
Mobile usage today is not just a trend but it is an essential shift in how people communicate with each other, interact with the world, and do business. According to a ComScore, in 2014 the number of mobile users surpassed the number of computer users and is showing strong growth over time, towards some point in ...
Two dominant manual testing approaches to the software testing game are scripted and exploratory testing. In the test automation space, we have other approaches. I look at three main contexts for test automation: 1. Code context – e.g. unit testing. 2. System context – e.g. protocol or message level testing. 3. Social context – e.g. ...
The Cloud demands that we be as nimble as possible, delivering features and fixes in almost real-time fashion. Both customer and provider rely on software development that can maintain quality while being light on its feet and constantly moving. In addition, Cloud-oriented systems tend to be highly complex and dynamic in structure — more than ...
The challenges with any automation effort is to know your capability. I’ve seen too many automation efforts begin and end with a tool decision. Generally these tools are very complex pieces of software that do many more things then we would ever use in our normal everyday testing. It even adds more misery to the ...
Introduction As a consultant and trainer, I am often asked by my clients and students how to deal with automated acceptance tests. One common question is whether automated acceptance tests should use the graphical user interface (GUI) provided by the application.
As I wrote in various articles, organization is one of the 3 key requisites for successful automated testing, the other two being test design and automation architecture.
Test automation can provide great benefits to the software testing process and improve the quality of the results…. but its use must be justified and its methods effective. The reasons to automate software testing lie in the pitfalls of manual software testing… As we all know too well, the average manual software testing program:
Jenkins is a Continuous Integration (CI) tool that controls repeatable tasks in software development. Check out this guide to see how TestArchitect seamlessly integrates with Jenkins to establish a CI environment for Automated Testing.
As our world continues its digital transformation with excitement in the advancement and convergence of so many technologies- from AI, machine learning, big data and analytics, to device mesh connectivity, nor should we forget VR and AR- 2017 promises to be a year that further transforms the way we work, play and take care of ...
Understanding the benefits and challenges of Automating ERP is critical. According to SAP, ERP (Enterprise Resource Planning) “is the core processes that are needed to run a company: finance, human resources, manufacturing, supply chain, services, procurement, and others. At its most basic level, ERP integrates these processes into a single system. But new ERP systems ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe