Check out my MoT article “Driving quality: The role of software testing in the automotive industry.” In this article, I walk through what testing looks like inside a car and how we work with ECUs, CAN networks, and test benches to simulate real signals. I also talk about what I learned when I stepped outside the automotive world and realised how different other testing spaces can be.
What you’ll learn:
What day-to-day testing looks like when software depends on hardware and real-world signals
How ECUs are tested using simulation, mocked inputs, and CAN-based tools
How automotive testing contrasts with web, app, and API testing
Why exploring testing outside your usual domain can shift how you think about quality
After reading, share your thoughts:
Have you ever stepped into a new testing domain and been surprised by how different the thinking or tooling was?
What parts of automotive-style simulation or system modelling feel useful in your own work?
Have you noticed “bubbles” in your testing career where you later realised you were only seeing one slice of the testing world?
What testing ideas from your domain do you think automotive testers could learn from?
Great article and really cool to have insight into automotive testing. I haven’t had as big a shift as yourself in testing, but I’ll do my best to answer your questions:
My testing career ironically started as a Test Manager in Public Transport. It was less about users and more about data flows from vehicles with GPS, Bus Services and predicting. So the biggest functional testing was data accuracy and data completeness. Users were actually low as it would be specific roles in organisations so at most you’d have say 5 users of the front end products. It was all about the data and the performance of processing it.
I moved from there to Court Management systems where it was the reverse. Obviously the data was important but it was driven by users so it was a lot easier to test and performance was all about simulating users.
Well very clearly automotive simulation would be massive for us. There is data entry but its drivers on ticket machines. Their input identifies what journey they’re running but to provide the products we do, we need to match that realtime data with the static schedule data. So imagine the problems with rogue GPS points or worse fault GPS, drivers inputting the wrong journey, drivers selecting their journey 3 stops in, leaving on time, early, late etc. the scenarios for vehicle simulations are enormous. So instead of simulating temperatures, we’d be needing to simulate all the above and more from 50 Buses to thousands.
All the time, which is why when I was first testing realtime data feeds I eventually learned you had to do impact testing of even the smallest changes on any downstream products. In the past, releases were rolled back where engineers were confident that there should be no downstream impact. If the data format wasn’t changing it shouldn’t impact but I learned the importance of data quality and data completeness.
Wow, first and foremost forgive if I make any outlandish assumptions about your work! The only thing that pops to mind is a lot of the testing is based on the data coming from all of those different ECU’s and make sure the data itself is transmitted accurately and boundaries trigger. But what can be missed from my domain is focusing on the user behaviour and expectations - in this case the driver. Why does the driver need this data? What do they do with it? Can the driver themselves trigger unexpected data e.g. accidents, motoring edge cases
I’m still trying to find a moment to actually sit down and read @andres_gr article. I’m so miffed we did not get a photo even if it was obscured, that shows the actual test rig, even part of it. But right now I just wanted to add before I forget to sit down with the article more, on GPS noise and signal noise:
As my experience although limited of GPS samples, is, yes it’s noisy data, and users will always find ways to make it look like they really are up to 5 meters away from their true position, but as long as you deadband and smooth and make sure you remove noise at one level, then it’s just noise in the data. BUT. In fact, when it comes to ECU’s (I watch a YT about catalytic converter sensors recently), noise is very necessary and tells the controller that the sensor is actually working correctly. So in some ways, noise is a data point in and of itself, which needs to be tested for, the actual smoothed value then, becomes less of a concern. So averaging out and filtering and using that “rough” value becomes perfectly legit as a sttrategy. It just becomes accuracy versus precision,
The only thing that pops to mind is a lot of the testing is based on the data coming from all of those different ECU’s and make sure the data itself is transmitted accurately and boundaries trigger. But what can be missed from my domain is focusing on the user behaviour and expectations - in this case the driver. Why does the driver need this data? What do they do with it? Can the driver themselves trigger unexpected data e.g. accidents, motoring edge cases