Automotive software testing: requirements and best practices

In this post, we’ll briefly discuss the automotive software industry outlook, recent automotive software advancements, legislative regulations around automotive software testing, and how companies with products that contain GUIs can use automotive software testing to remain competitive in an increasingly unstable and challenging market.  

An outlook on the automotive software industry

The automotive software market is expected to grow rapidly by 2030, with projections showing it will increase from $31 billion (2019) to approximately $80 billion. This translates to a CAGR of over 9% across the market, and more specifically, 9.1% for Infotainment, connectivity, security, and connected services.

This means that the automotive industry, like many others, is experiencing unprecedented levels of innovation, technological advancement, and in turn — competition. And while the manufacturers of vehicles and their parts race to stay profitable and at the top of the curve, the battle is being won in the background, over lines of code.

Automotive testing at a glance 

When most people think of automotive testing, images of crash tests, speed tests, and other mechanical interventions come to mind. Though, in reality, most automotive testing happens long before car parts come together.

A single car has about 30,000 parts, which are supplied by dozens of  Original Equipment Manufacturers (OEMs) that collaborate together to create the vehicle. Each part, whether hardware or software, is tested hundreds of thousands of times before the final assembly of the car, and even more before it hits the road. 

Automotive software testing 

The cars on the road today, both your standard sedans and top-of-the-range performance vehicles, are driven by software. For a vehicle built in 2022, it’s possible to have as many as 150 Electronic Control Units installed. 

An Electronic Control Unit (ECU) is a small computer that controls a particular function in a car. Before ECUs, mechanical systems used ignition timing, fuel, air and engine rotation to complete functions. Now, everything that needs to happen is programmed into the chip inside the ECU. 

Some examples of ECUs you can find in a car include critical-function ECUs like the engine control module (ECM) and brake control module (BCM) or non-critical ECUs like the ones inside the car’s info-navigation system, or in the general electronic module (GEM) that controls functions like locking and unlocking doors, opening windows or controlling the air conditioning.

Considering that each Electronic Control Unit is functionally a tiny computer, rigorous software testing must be conducted to ensure its functionality, usability and safety. 

The reality is that traditional automotive testing is expensive, time consuming and not easily repeatable — so of course, we have technology to thank for an answer to the problem: Hardware-in-the-loop (HIL) and Software-in-the-Loop (SIL) testing. 

Software-in-the-Loop (SIL) testing 

Software-in-the-Loop testing tests and validates software’s code in a simulation to squish bugs, improve code quality and significantly reduce build time. 

As car brands and OEMs continue to innovate to gain a competitive edge, the real battle is won over lines of code. Regardless of the type of product (safety, dashboards, navigation systems, or others) software must be tested extensively before being approved for use in a vehicle.

Some benefits of SIL include: 

  • Code can be tested periodically, as each segment of the program is completed – instead of waiting for the final build 
  • Tests can be automated and run simultaneously
  • Test results are shareable and easy to analyze
  • It’s separates software from hardware development, so software manufacturers can continue to innovate past the hardware industry’s pace 
  • There’s no need for a dedicated testing bench (like in HIL testing that we’ll discuss below) 
  • SIL testing is easily scalable, repeatable and faster than manual testing

Hardware-in-the-Loop (HIL) testing 

HIL testing is, as it sounds, a method of testing and validation related to the pieces of hardware in a vehicle. These simulators are more or less models of the final product, which are then thoroughly tested before connecting the real ECU to the test system. 

HIL test benches emulate actual car engine dynamics through the execution of mathematical models in real time, using data input from devices like cameras and radars. Generally, HIL testing is more costly and time consuming than SIL testing, so it’s done after SIL testing. 

Automotive software testing is important for reasons other than purely on-road safety — for example: cyber security, OEM trust and reliability, and car brand health and image. 

Legislative requirements in automotive software testing 

Naturally, the regulations around testing on both hardware and software components of a vehicle are rigorous. 

ISO 26262: Road vehicles - Functional safety 

The main legislative requirement for automotive safety is ISO 26262: Road vehicles — Functional safety, which applies to mass-produced passenger cars, as well as provides guidance on E/E systems in buses, trucks, trailers and semi-trailers. 

ISO 21434: Road vehicles - Cybersecurity engineering

ISO 21434  is a follow-on standard based on ISO 26262, except it specifically focuses on cyber security in the design and development of automotive software and subsystems. Topics covered in this standard include risk management and mitigation, risk assessment, continued security, security management and more. 


AUTOSAR stands for AUTomotive Open System ARchitecture, “a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry”. The aim of AUTOSAR is to create a worldwide open and standardized software architecture for automotive ECUs. While OEMs and manufacturers are not required to participate in or comply with AUTOSAR architecture, many of the world’s leading companies do. 


MISRA is an automotive safety organisation made up of suppliers, engineering consultancies, static code analysts  and OEM manufacturers. First published in 1998, their coding guidelines now cover systems build on C and C++ coding languages. Again, while MISRA is a non-mandatory set of standards, it is widely adopted across many industries as it facilitates the development of safe, secure, and portable code for safety and security critical systems.

Best practices for companies looking to carry out automotive software testing

While the product’s function in the vehicle (safety critical, mechanical, aesthetic) impacts the level of safety testing required, best practices in software testing are consistently applied, no matter the product. 

What does need to be considered on a case-by-case basis is what tool is right for the job. For example, OEMs that produce braking systems may need complex HIL-testing, while infotainment or navigation systems may need only SIL-testing. 

Automated GUI testing for automotive products 

Squish is an automated GUI testing tool for cross-platform desktop, mobile, embedded and web applications. In terms of automotive testing, Squish is generally used for testing navigation systems, touch panels, dashboards and front panels. 

Why Squish works for automotive GUI testing

User interfaces are getting more and more animated, with graphics moving fast with incredible levels of animation. In this way, testing from the GUI perspective is challenging because everything is constantly changing, and you need to ensure the state of the application and your test are synchronized.

If we consider the animations as a human, testers would need to manually take a screenshot, then compare if an indicator is in the correct place, right colour, being animated at the correct speed (if it is intended to move)

With Squish, our goal is to emulate end-user behaviour. Squish automatically interacts with the application exactly the way the end user would do (click, drag, drop, touch). Squish can also take screenshots to check the current state of the application, and if the images are rendered the way the design and development teams intended. 

Squish features that mitigate risk include image-based testing, that use multiple verification points that check if the visual appearance is as expected. It also supports Optical Character Recognition (OCR) engines that help verify if text and numbers are displayed on the screen as intended.


Want to see Squish up close? Get your free trial right here.

Explore Qt in Automotive