So the news has had some interesting public bugs. For example GM trucks had software bugs, which caused fires and a big recall/software update:
http://spectrum.ieee.org/riskfactor/computing/it/gm-recalls-370-000-pickup-trucks-for-software-update-to-reduce-fire-risk
Let’s think about conceptual costs resulting from this bug:
1) So this makes the news = bad PR and maybe sales impact loses?
2) Cost of the recall notice = money cost
3) Time in the shop and updating the software = more money cost to dealers
4) Maybe some fires and resulting law suites = could be a lot of money cost to company.
I don’t know why testing did not find this bug or how much it might have cost in testing with a “break it” view point as my book, Software Test Attacks to Break Mobile and Embedded Devices” talks about, but I might be willing to bet the cost of testing would have been less than these conceptual costs from when the bug is found in the field.
Teams and testers need to think of these conceptual costs when considering the ROI of testing. Places I worked looked at the money spent on testing (millions of dollars in some cases) as cheaper than losing much more in these conceptual costs. Too many product managers only look at the cost of development (including seeing test as tax which should be minimized) and do not consider the costs of bad devices in deployment. It is some else loss to pay these “in field” costs. This is a short sighted view of the embedded device space.
breakingembeddedsoftware 