Q
Problem solve Get help with specific problems with your technologies, process and projects.

Embedded software: Testers must consider hardware and software functionality

When testing embedded software, testers must take into account the platform, operating system, hardware and the purpose of the software being tested. Read this expert response, which recommends considering all aspects of the product.

Is it necessary to understand the hardware as well as the software when testing embedded software?

I believe there are many aspects that must be considered in all forms of testing. Among them is the hardware itself. In some instances, the application may be a page or application transferred to a different environment or platform. In some instances, the application may not even be seen by a user. 

When testing on Windows or Linux or AIX or nearly any other type of platform, you need to have some awareness and understanding of the environment, so why not when testing embedded software? You need to understand the platform, both the hardware and operating system, as well as the intent and purpose of the software under test.

There are some software folks who will blame faults on the hardware. At the same time, hardware folks will do the same thing and blame the software folks. The fact is, testers need to have an appreciation and understanding of both the software and the hardware. It seems to me that the questions around the “sudden acceleration” in cars made by Toyota can fall into this type of a category. I don’t know what the cause is. I do not have enough of an understanding what all the components are, but I think this makes for an interesting example with many possibilities in play.

The report released this past March by the National Highway Traffic Safety Administration found “no electronic flaws” that could be identified as causing unintended acceleration, the documents released show (available at http://www.nhtsa.gov/UA) interesting reading for those not daunted by the sheer mass of information. 

It strikes me that oftentimes when software developers look to blame the hardware, it tends to be a failure to understand how the software interacts with the hardware. The reverse can also be true. 

Without a good understanding of the hardware, I am not convinced that a defect can be readily isolated to either hardware or software, or both. When testing, we need to be open to unusual occurrences and realize that “one-off” results may not be as impossible to recreate as they appear. When the hardware and software experts deny causing an unusual or hard to reproduce issue, it is up to us as testers to keep a clear head and observe as much as can possibly be observed, dismissing nothing that comes into our view as “that can’t possibly be related.” 

It is probable that there are multiple things happening we are not recognizing. The combination of these things can be the cause, not a single factor. If you focus only on the software and not on the hardware, how can you determine if the product will serve the purpose it is intended to serve?

This was last published in May 2011

Dig Deeper on Software Test Design and Planning

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close