The InventorAs 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.
The ModellerTesla 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 & ModellingAdhoc 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 TeslaTesla 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.