Colarado Springs, 1900, and a round wooden building has been constructed 100 feet in diameter. Within the building a metal spike, fifty feet high, extends from floor to ceiling, this continues for another 70 feet into the desert air. A thin man sits on a wooden chair reading a hand written scientific text not more than 5 feet away from the spike. Suddenly a roar of tumultuous proportions fills the room, neighbours 10 miles away step out of their homes to see what has disturbed them. A shower of sparks erupts from the metal spike and tendrils of lightning arc around the man as millions of volts are discharged into the wooden room. Nicola Tesla smiles, and closes his text, his invention successful.
As an inventor, Tesla embodies the entire development lifecycle. The inspiration of genius, the feasibility study, the prototype, through to the documented patent. Every role in the development process can learn from Tesla, but as a tester I am most interested in Tesla’s ability to model.
Born July 9 1856, Nicola Tesla was a visionary inventor who held patents and prototypes for a staggering array of scientific achievements of which the following are but a few: a radio controlled boat in 1890, the Tesla coil a prominent feature in every celluloid mad scientist’s lab, creator of the Niagra Falls polyphase AC generator, robots, helicopters, radio and, it has been rumored, even the electric light bulb.
Tesla constructed models of his inventions in his head; to scale, with the correct materials and using the tools that he would use to construct them in real life. Having built a mental model he could then subject it to analysis, tests, and make changes until he was satisfied, then and only then would he build it.
“The pieces of Apparatus I conceived were to me absolutely real and tangible, every detail, even to the minutest marks and signs of wear.” 
Unlike testers, Tesla had the benefit that he worked alone. He would conceive, build and test the systems he required. As testers we have to take in to account the need to communicate; with our fellow testers, the development teams, the users and ourselves (nine months down the line after we have forgotten why we created that test in the first place).
Tesla’s prestigious success is surely aided by his ability to model. It would be a mistake to suggest that as testers we build models of the system in our head and then conduct the tests there. But as software development professionals how often do we fail to take the models that we have out of our heads and on to paper, how often do we fail to document the derivation trail of our tests?
Testing & Modelling
Adhoc testing typifies the building of, and testing from, an unconscious model in our head rather than a documented or conscious model. If we do this then we have no justification for measures of completeness or coverage. The model in our head allows us to distinguish between an error and a pass but it may become difficult to justify such a decision if, on the next stage of testing, our pass is deemed a false positive (a test that actually failed but we marked it as passed).
Tesla’s model was as good as the real thing. The models that we use are not. Our models are maps, they represent the system but they are not the system. We build models to construct tests from, but we do not apply those tests to our model, we apply those tests to the system that someone else has built. Our testing is partly there to try and identify the differences between their system and our model.
Late in his life Tesla made some fantastic claims: free energy, cable free energy transmission, and death rays. But Tesla was ridiculed and very quickly after his death fell into obscurity. Tesla had nothing but excited visionary notes and his models to support these claims, but his models were in his head.
So to be good testers we sometimes have to learn from what Tesla did not do and what Tesla did inappropriately.
Learning from Tesla
Tesla worked in secret with dramatic announcements to the press, we instead have to document and inform from the very moment that we start thinking about testing. We should be tactful in our announcements. We have to document our models and we have to document the tests that we derive from those models.
We always derive our tests, whether we think we do or not. Our tests are a result of applying strategies to models, simple strategies like ensuring that we can’t switch from a state to any other state unless it is documented in the state transition diagram. Heuristic strategies based on prior experience with similar products, which should be documented as test conditions. Testers use a multitude of strategies on many models.
What we have to understand about models is that if we construct models of a certain type e.g. state transition diagram. Then there are predefined strategies that we can apply to those models in order to construct tests. By having both the strategies and the models we can tell how consistently we have applied those strategies and how well we have built the models.
As testers we are in the position that if it is only in our head then it simply doesn’t exist and we too would be ridiculed if we conducted our testing in this fashion. We cannot claim that we have achieved an adequate level of coverage unless we have a model of our intended scope.
Modelling is as fundamental an activity in software testing as it was for Tesla and engineering. As Tesla himself said, “There is scarcely a subject that cannot be mathematically treated and the effects calculated or the results determined beforehand from the available theoretical and practical data.” 
References and consulted texts:
 Tesla: Man out of time, Margaret Cheney, 1981, Dell Publishing
 Strategies of Genius: Volume III, Robert B. Dilts, 1995, Meta Publications
 The man who invented the twentieth century, Robert Lomas, 199, Headline book publishing
 In search of Nikola Tesla, F David Peat, 1983, Ashgrove Press Limited
This essay originally appeared on CompendiumDev.co.uk on 4th January 2002 as a ‘journal notes’ this was in the days before I had a ‘blog’ setup and still had a ‘web site’. It seems more like a blog post than an essay so I’ve moved it over to EvilTester.com.
You will need a Github account to comment. Or you can contact me with your comment.
I reserve the right to delete spam comments e.g. if your comment adds no value and its purpose is simply to create a backlink to another site offering training, or courses, etc.