Well. After taking a somewhat lengthy break, and with the help of Dragon 11.5, I'm going to try my hand at this blogging stuff again.
This time I want to talk about symptoms. In my prior blog, The Microsoft Calculator Challenge, I uncovered and described a series of symptoms of failure of the Microsoft calculator function. Each of the symptoms is indicative of a defect in the calculator code. The specific defects are not mentioned. But then, my function as a tester is not to determine or diagnose the specific defect causing the symptoms I have uncovered.
Having spent a good part of my career as a diagnostic engineer, I am familiar with the techniques and skills needed to trace from a symptom that my test discovered to the specific defect causing that symptom.
I recall an instance while General Electric was installing a new computer system at Mobil Beaumont in Texas in competition with the simultaneous installation of a new system by IBM. When I arrived at the site there must have been a dozen engineers, a couple of managers, and some technicians working on the problems. We were serious about getting that system up and running. I was brought in for the purpose of diagnosing the problems, reporting them, and then someone else would fix them.
There were many issues. One of those issues was that the printer would not print. Hopping from issue to issue, I took one look at the printer and saw that the "online" light was out. I pointed this out to the nearest technician who said, "It's just that the light is burned out. The problem is that the printer won't print!" And I said, "Just replace the light, we'll deal with the printing later." So he replaced the light.
Sometime later I returned to the printer problem, loaded up the diagnostic, and the printer ran fine! The printer was working! That was most unsatisfying. Why would the printer start working when all we did was replace the stupid lightbulb?
With some effort at root cause analysis, I found that the printer design had a circuit for returning an error to the printer interface when one of the lightbulbs was burned out. Our engineers had logically ORed the printer's error lines into our single printer error line. When that error line was asserted by the burned-out lightbulb, the printer would not print. Minor design change; problem solved.
But was the problem really solved? What about the technician that assumed that the burned-out lightbulb was not a significant symptom of a system defect.
Would that Microsoft would heed the complex and insignificant symptom cited in my challenge. Indeed, in the past, Microsoft has paid some attention to the trivial and insignificant symptoms that I had identified because they put in some kind of "fix." Was this because Microsoft might have been embarrassed by the malfunction of such a "simple" function? Were these symptoms an indication of lack of attention to detail? Is that a pandemic problem?
I have mentioned in other forums that the significance of a defect is not necessarily related to the significance of a single particular symptom of that defect. The only way to determine the significance of a defect is to know the defect. To know the defect you must diagnose the defect. Often the most significant portion of the repair cost of a defect is the diagnosis of that defect. It is no wonder that so frequently we repair the symptom and not the defect.
The technician wanted to ignore the burned-out lightbulb. Microsoft repaired the symptom of the 2+2 = 8 failure but not the defect. All of this is symptomatic of something. These assumptions about symptom importance are significant symptoms of a broken process. I am wondering, "Just what IS the defect?"