Don’t stop me now

If you have ever tested medical devices, or other safety critical software products, you should know that bugs on production are not that common in such a context.
Anyway, you can come across one every once in a while and see how all the people involved tend to take the situation very seriously, since it usually represents a great opportunity to learn something of extraordinary importance: actually the best lesson to avoid making the same mistake again.

So, some years ago, while serving as a software tester on medical devices, one day came the news of a worrying complaint from a laboratory which used an instrument developed and commercialized by the company I was working for.

The issue was pretty serious: the device in question had suddenly stopped functioning and rebooted just in the middle of a job run, that is, a set of assays which were being performed on a bunch of blood samples.
Purportedly, one of the most effective ways to upset a lab technician.

Different people within my team (programmers, testers, managers) started investigating how that could have happened, all of us being practically flabbergasted by the issue.
You know, professionals dealing with regulated environments don’t really enjoy these kinds of surprises.

After a difficult and deep investigation, which lasted several hours, the reason for the issue was eventually exposed: there was an internal time-out somewhere —something nobody was aware of, of course— which made automatically reboot our instruments after about three weeks of continuous operations.
The thing is not only was nobody aware of that technical specification(?)/limitation(?) —which had to be removed, of course—, but we also realized that we would never have discovered that problem by ourselves.
Can you guess why?

#FromArbitraryTechnicalDecisionToBug