Zen, motorcycles and Software Testing
While I was listening to an exceptionally thought provoking talk by Dan North on “Where is the Quality in Agility” , I heard him talking about a weird named book. Realizing that this book must be some thing, I got hold of it some time ago and am reading it now. It is called ‘Zen and the Art of Motorcycle Maintenance: An Inquiry into Values’ by Robert M. Pirsig. I know what you are thinking and this is what I was thinking when I first heard the name: How Zen and motorcycle maintenance are of consideration to guys like us who are in the pursuit of Software Quality? The next few paragraphs will answer, don’t worry.
(the original photo is here: http://venturearete.org/ResearchProjects/ProfessorGurr/gallery/Pictures-Robert-Pirsigs-original-1968-trip )
This bestseller on a fiction based philosophical nature was rejected by 121 publishers before it was printed. One more reason for me to celebrate when I get rejected next time 🙂
What a book holds can only be seen by reading the book, but here are some lessons that I have gotten so far for the benefit of software testers. Caution: I haven’t finished reading the whole book yet, so there could be even more stuff.
A motorcycle is a System and so is software. At one point Pirsig explains how he or mechanics troubleshoot problems and he notes:
“The box “motorcycle” contains the boxes “components” and “functions.” The box “components” contains the boxes “power assembly” and “running assembly,” and so on. …The overall name of these interrelated structures, the genus of which the hierarchy of containment and structure of causation are just species, is system. The motorcycle is a system. A real system.
To speak of certain government and establishment institutions as “the system” is to speak correctly, since these organizations are founded upon the same structural conceptual relationships as a motorcycle. They are sustained by structural relationships even when they have lost all other meaning and purpose…
But to tear down a factory or to revolt against a government or to avoid repair of a motorcycle because it is a system is to attack effects rather than causes; and as long as the attack is upon effects only, no change is possible. The true system, the real system, is our present construction of systematic thought itself, rationality itself, and if a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory. If a revolution destroys a systematic government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves in the succeeding government. There’s so much talk about the system. And so little understanding.”
Here you go. When you are testing a system, you should make a model of how in your thinking the system is modeled and then apply your skills to see if the system behaves as you modelled it. This is the number one principle to succeed as a tester.
Similarly when systems fail due to a bug, look for the real underlying problem otherwise fixing that problem will still result in faulty system as the patterns will repeat themselves until rectified.
How highway maps are incorrect about the country roads: Since the author is on a road trip and have a map to use, here comes a classical comment:
“Moreover, you discover that the highway maps are often inaccurate about county roads. And from time to time you find your “county road” takes you onto a two-rutter and then a single rutter and then into a pasture and stops, or else it takes you into some farmer’s backyard.”
Hmmm… when you are testing a system and relying only on a map (test plan), you will not get the details of less traveled country roads as the test plan writer has never explored them. You’ll have to move around those roads to get to know exactly what the territory is rather than relying on the map. One more reason to do Exploratory testing more often.
An experiment never fails. As the author explains the philosophy behind motorcycle repairing and how it is truly scientific in nature, he notes:
“A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his efforts are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to nature. The TV scientist who mutters sadly, “The experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad scriptwriter. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.”
Like a motorcycle mechanic, a software tester also conducts an experiment on the product. So many times, we tend to pretend as if we know what the result of the experiment will be. We perform the tests as if we know the eternal truth that we call ‘Expected Behavior’ and compare it with the ‘Actual Behavior’ of the system as we perform our tests. That is wrong in itself as we don’t know the outcome of the Experiment and Experiment never fails. It just proves one thing or the other and we continue conducting our next experiment. May be that’s why test cases is not testing.
What books are you reading these days? And do they ever relate to software quality and testing? I bet they do.