Is it necessary to understand the hardware as well as the software when testing embedded software?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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 first published in May 2011