 |
Home > Detail: Lucky and Smart
| A StickyMinds.com Original |
| | |
Lucky and Smart
By Michael Bolton
   
Summary: Charles Darwin was certainly a great scientist, but his career and his discoveries were also strongly influenced by serendipity and luck. What could this great explorer and scientist teach us about testing? | | |
|
|
 |
Just after the Conference for the Association for Software Testing in Toronto in July 2008, I had the good fortune to spend an afternoon wandering through the Royal Ontario Museum with some colleagues. We were there for the featured exhibit, "The Evolution Revolution," a survey of the life and work of Charles Darwin. Darwin is known as one of the greatest scientists in history. And, as the exhibit showed, he was also a remarkably lucky man.
For one thing, his famous voyage on the Beagle almost never happened. Darwin's mentor and sponsor, John Henslow, had intended to take the ship’s naturalist position himself, but because he had a wife and a new baby, he decided against a long trip at sea. Henslow’s first choice for a substitute, Leonard Jenyns, also declined the position in favor of a new job. Robert Darwin, Charles's father, forbade his son from going on the adventure but offered an out: "If one man of common sense assents," he said, Charles would be permitted to go. Charles consulted with his uncle, Josiah Wedgewood. They overcame the elder Darwin's objections, and, true to his word, Robert Darwin gave permission.
The Beagle set sail in late December 1831. While at sea in February 1832, Darwin recorded his excited realization that the voyage would allow him to observe geology in addition to biology and botany. Later that month, he arrived in South America to start exploring. His thinking was influenced by experiences with a group of gauchos north of the Rio Negro in August 1833. These men often hunted and ate a large flightless bird called the rhea. They told Darwin about a similar, smaller bird, but in spite of thorough searching, Darwin was unable to find a specimen. A few months later and several hundred miles south, near Port Desire, the ship's artist, Conrad Martens, shot a small rhea and served it up for dinner. Not until halfway through the meal did Darwin recognize what was sitting on his plate. He rescued the carcass—head, neck, bones, feathers, and a near-complete skin. Darwin realized that Martens hadn't shot a small rhea, but a species different from the larger bird, with distinct plumage and eggs, later confirmed as the lesser rhea. This incident was one of the triggers for Darwin's nagging question—why do two similar but separate species often appear so close together?
The year 1835 brought a remarkable sequence of events. In January, Darwin happened to be present and recorded his observations as Mount Osorno erupted. On February 20, the town of Valdivia was struck by "the most severe earthquake experienced by the oldest inhabitant," and Darwin was present for that, too. The quake flattened the town of Concepción and an ensuing tsunami drowned nearby Talcahuano. A few days later, Darwin recorded that the Beagle's Captain FitzRoy had observed putrefying mussels ten feet above sea level—indicating that the coastline had risen by at least that much in just a few days. In April, while in the high passes of the Cordillera, Darwin recorded his observation of petrified trees that closely resembled the living trees thousands of feet below. In his journal, he linked his observations with the earthquake, concluding that the land rose slowly, by fits and starts, and that change could happen over enormous spans of time—which he later realized was enough time for natural
selection to take its course.
Darwin observed carefully and took notes assiduously, but it's impossible for one person to document everything or to anticipate what might be important. When he returned home, he brought with him an extraordinary collection of specimens, including many birds from the Galápagos Islands. Darwin believed that he had found several new species, but John Gould, an expert ornithologist, noted that despite their outward differences, they were all finches. Gould also noted that Darwin had unwittingly bagged three new species of mockingbirds. Darwin realized that while the birds were all from the same region, they were from different islands, but he hadn't kept exact records of the specific island on which each specimen had been found. Fortunately, Captain FitzRoy had collected many of the same species, and he had kept notes that allowed Darwin and Gould to determine the provenance of the birds.
The Museum's wonderful Darwin exhibit resonated with a number of ideas about testing. Many of us started our careers as testers by accident. As we reflect on what we're going to test, we often expand our models of what we're going to cover. We're often lucky enough to make important observations and discoveries by a combination of diligence and chance. We often make incomplete observations or keep imperfect records—but we can compensate for that with teamwork. We might not obtain all the answers, but we can often get partial answers that might be sufficiently useful to trigger better questions, more complete answers, and deeper understanding.
FitzRoy had planned the journey diligently, but much of what he and Darwin discovered was unplanned and unscheduled. Darwin was a brilliant observer and scientist, to be sure, but many of his insights were triggered by serendipity and luck.
Good testing is like that. Even when someone tests incompetently or aimlessly, he obtains some product coverage—and may trip over some bugs by accident. A more capable or better-prepared tester typically tests more deliberately, consciously, and intentionally, but still may obtain some coverage incidentally, unconsciously, or accidentally. We never know what we might find—and sometimes we don't even know immediately that we're finding it. If we're executing functional tests on a pocket calculator, for instance, and the answer appears quickly, we've achieved some kind of performance coverage whether we notice it or not. Conversely, I was investigating connectivity features on a mobile phone recently. Even though the phone connected properly, I experienced a noticeable and annoying delay in the user interface. I had found a performance problem, even though I hadn't set out to find that kind of problem. That's why test evaluation shouldn't stop with a passing or failing test; in excellent testing, we continuously look around and ask, "Is there a problem here?"
When we're engaged in testing, we're constantly exploring, observing, and evaluating—or anticipating those activities, as Darwin was in the first month of the voyage. At any point, an observation, a pause, or a distraction might bring a new discovery or an expanded notion of test coverage. When I stumble on something, I ask myself, "Is there another quality criterion that I could consider that might matter to some client? Have I seen something like this before? Are there more things like this that I could compare? Are there more places like this to look? Are there more places where I can apply this way of looking?"
Traditional writing about testing provides plenty of focusing heuristics in the form of specific techniques to perform and conditions to watch out for. But it's also important to consider the dynamic between focusing and defocusing—paying attention to details, then zooming out to the big picture and back again. When you're observing an ant, defocus occasionally to see the colony and its dynamics. When you're looking at the anthill, pause every now and again to check the behavior of individual ants. When you've done both for a while, take a break and come back to maximize the opportunity to see new things with the same old eyes.
A postscript: As I was finishing this article, I needed to refer to some material on Darwin, and I also needed a title. I opened up my browser history and noticed
that one of the articles that I had been reading before starting to write—an article that had nothing to do with Darwin or testing—was titled "Better To Be Lucky Than Smart." As testers—like Darwin—we need to be both. {end}
What can testers learn from other scientists and other disciplines?
Join the conversation below or start a new one in the Member Comments section.
About the Author
Michael Bolton lives in Toronto and teaches heuristics and exploratory testing in Canada, the United States, and other countries. He is co-author, with James Bach, of Rapid Software Testing and a regular contributor to Better Software magazine. Contact Michael at mb@developsense.com.
Back to Top
|
