Four Major Pitfalls that Derail Efforts to Test Embedded Software

Embedded software is quite different from application software. It is less visible to the end user; however, it is a complex and crucial component that makes sophisticated medical, industrial, automotive, and security equipment work smoothly and reliably. It is the heart of the systems to which we entrust our lives. Thus, testing for embedded software differs from application testing in many ways: it requires higher code coverage and presents considerable challenges for embedded companies.

In cooperation with LTM Research, an independent research company, Auriga has conducted a unique survey that unveils current trends in embedded software testing. We asked 55 embedded companies to compare their software-testing approach against those of their peers and highlight major pitfalls that derail their efforts to test embedded software.

Based on our survey, here are four common challenges in the embedded software-testing process.

  • Hardware dependency and lack of physical access to hardware

Hardware dependency and limited access to hardware are serious inconveniences that cause numerous difficulties for test engineers. Simulators and emulators may not accurately represent the behavior of the actual system or may modify it in various ways. It increases the testing time and the likelihood of bugs, making the bug fixing more expensive. As a result, continuous testing and integration are hindered.

And while hardware dependency is something you can’t avoid, early direct access to the tested devices would surely ease the pain. Auriga’s survey shows that over 80% of the leading embedded companies have constant access to the test hardware—obviously, it is one of the main factors defining leaders in embedded software testing.

  • High ratio of hardware defects

Identified defects may be related not only to software but to hardware as well. Moreover, the software may work fine with one version or set of the hardware and fail with another. Differing defect ratios among hardware is definitely a challenge for the testing process. To mitigate risks and get the best of the situation, some R&D is highly recommended.

  • Non-reproducible defects

In the embedded system case, defects are usually harder to reproduce. Consequently, large volumes of data are needed to discover the defects’ causes, and testers have to consider every defect occurrence much more seriously than in customary cases.

  • Software update limitations

Embedded systems require continuous software updates for different device drivers, kernel upgrades, security fixes, etc. Software update limitations make it very challenging to find bugs for a particular software version during the testing process.

There are several other challenges that did not make this list: lack of complete test availability for open-source software, compliance testing, test automation, and more. The challenges may vary depending on the type of testing being carried out, but working on them is a must—reliability is the top priority when it comes to embedded systems. You can find more insights and ideas for embedded systems testing as well as lessons learned and challenges met by Auriga teams in our white paper.

In our previous articles, we found out that most developers are dissatisfied with the embedded software-testing approach in their organizations; revealed the unique benefits of DevOps and Agile approaches; discussed the role compliance tracking plays in the embedded software development cycle; and identified the key characteristics that define an embedded software-testing leader.

Join us and follow our news to review your industry peers’ thoughts on how embedded testing has changed and learn what separates the leaders from the followers in software-testing practices. Full study outcomes are coming soon!