Unfortunately, or fortunately, this post is not about automatic testing. According to the author of this interesting post, James Bach, automatic testing is as feasible as automatic programming. That is, not very feasible. Yet, at least.
In a very nice story, James writes a program while his non-programmer and non-tester sister, Erica, stays by his side. He walks through his logic while writing and his sister points out issues while he does so. Despite not having any computer science background, the mere presence of an interested companion leads to better, less issue-ridden programs. This made me remember something from a long time ago, when I was told about the somewhat infamous rubber duck test.
For those that don’t know, the rubber duck test is when a programmer, aloud, describes how his or her program works…to a rubber duck. It sounds ridiculous, but the mere act of trying to explain ones own work in an understandable way can lead to discovering issues that might otherwise be unnoticed. A design fault that seems obvious in hindsight but was looked over as the programmer becomes tunnel focused while in the midst of programming.
This very neatly explains the need for a tester, or at the very least something to get a developer to think in a different way about their work. Along with this, it also demonstrates the natural problem solving nature of a programmer that seems inherent. The need to resolve the conflict of a companion not understanding you is something familiar to me. My middle-school aged brother sometimes asks me about stuff I’m doing, which very many times turns out to be classwork. I have surprised myself with how much I wanted to clear up any looks of confusion I got when attempting to explain a mathematics problem or a program I was having issues with.
This natural motivation of wanting to be understood can lead to much deeper introspection, especially when the other party is not very familiar with the concepts being explained. It often leads to a long series of “Why?” questions. Something James himself calls ‘drilling down’, continuously being asked for more details. Trying to frame key concepts one believes they understand can lead to realizing flaws in ones understanding or incompleteness.
I really enjoyed this article, the story was nice and familiar. It made me realize how basic a necessity a tester, or at least just someone other than the programmer or something else other than the programmer is to creating a program. Or while not a necessity, such an incredible boon to the entire process, that it should be.
Original post: http://www.satisfice.com/blog/archives/852