.. is that in an embedded system EVERYTHING may affect timing of time critical issues. An an example some 'inherited' I/O totally untouched started behaving erratically when a totally unrelated function had a feature added. This did show that the 'inherited' I/O was badly coded and depended on the main loop executing in a given time (research showed that before the modification it was 'on the edge' way more than permissible and it was then later found out that the bug was not new, just that the mod made it frequent.

In a PC system where you have an OS that (hopefully) overrules anything you write, the relation to I/O is broken and thus testing MAY have some benefit.

Thus
1) there is no such thing as regression testing for an embedded system
2) ANY testing is, at best, giving 'comfort' it can not give 'proof'
3) anyone that relies on testing should find another career, the base for bug-free code is not testing but design.

Erik