Under control

As I explained within the previous article of this miniseries on software testing, bugs on production are not very common when you work on medical devices.

However, any complaint coming from the field —that is, from hospitals or medical labs— is taken very seriously: for starters, an investigation needs to be conducted.

So, some years ago, while serving as a software tester on medical devices, one day was I given the task of trying to reproduce an issue reported by a lab technician.

He was complaining about the fact a quality control, that is a kind of job run on a specific benchmark material (instead of blood) in order to somehow calibrate and certify the accuracy of the assay itself, had not automatically executed at the expected time.

Which was really surprising, especially taking into account that both the programmer and the tester historically in charge of that functional area for many years were very experienced.
Now, I don’t remember if the experienced tester was busy with something else or on holiday at the time, but I do perfectly recall the skepticism in the programmer’s face.
He likely thought it must have been a user error. Hopefully, a not reproducible issue…

Being a strong believer that something which happened to a customer (in production environment or in the field) tends to be reproducible by definition, I enthusiastically took on that challenge.

Anyway, I quickly realized that the issue was not easy at all to reproduce.
What’s more, the complaint was affected by a lot of noise: several conjectures about the reason of the issue made by the lab technician did nothing but distract me from trying to figure out what the cause of the problem really was.

So, one of the first and most important things I learnt from that investigation¹ was that separating facts from conjectures is crucial.

#FromArbitraryTechnicalDecisionToBug