One of the best things about working in the computing industry is the people you meet. I've met characters from all walks of life, especially in testing because not everyone is from a computer science background. For this reason--perhaps over all others--I go to conferences. Sure, the presentations are (mostly) good, but I've found that the most interesting conversations happen in the bar or at dinner after all the projectors have been turn off for the day.

With this in mind, I remembered a conversation I had with Harry Robinson at the 2005 STAREAST conference. Harry and I talked about our "spousal units" (his terminology, and I'm grateful for him letting me use it), and how they help us with our jobs; thus the title of this article. Most people have a "significant other unit," be it a wife, husband, boyfriend, or girlfriend. Some may even be on higher versions! However, to many of us, they are often a source of inspiration or a sounding board despite their (perceived) lack of knowledge of our discipline.

At the time of the conversation, I was transitioning between jobs and a coast-to-coast relocation. As all our worldly possessions were winging their way across the country, my wife and I were holed up in a hotel in Orlando for the week. Avoiding the cliché recommendations to go shopping, she though it would be interesting to hang out with me and the other delegates, sit in the back of some of the talks, and find out more about the area I work in. Now, my wife's into archaeology, so I doubt you'd be able to find two more diverse disciplines!

Aside from this voluntary participation, my spousal unit regularly endures a number of ordeals related to my work, and sometimes I'm not always responsive to what she suggests. I ask for her opinion when I get stuck while writing a paper, article, report, or some other such document. She reads what I've got so far and tells me if it makes sense, or we discuss where I'm heading with the message. If a program I've written is behaving unexpectedly for unknown reasons, I explain to her what it's supposed to be doing: Numerous times I've found the solution just by describing the operations in basic terms. Before I give any presentation, I run through the slides and we talk about the main points I want to get across.

Now, because we work in substantially different fields, she thinks that her involvement is redundant and is sometimes afraid of asking stupid questions, but inevitably it always makes my work better. Some of the questions she asks are thought provoking--from, "How do you know that the oracle is correct?" (commenting on Harry's talk about model-based testing), to "Why would someone do that after the program has already said it can't take a number that high?" (asked after James Whittaker had crashed PowerPoint for the nth time giving it unexpected data). The reason I appreciate this interaction is because it forces me to take a step back from the assumed knowledge and jargon and make material more understandable and accessible, or think from a different viewpoint, which is always a good thing.

It's well understood that the most productive research groups consist of people from a variety of backgrounds and disciplines. With the specializations in all form of science, the most interesting discoveries are in the gaps--when an old approach is applied to a new system, or vice-versa. We can't all afford multi-disciplinary, multi-cultural teams to work with us, so our significant-other units come in as a low-cost alternative.

Learning from others is an important aspect throughout life, but in the computing industry we have become known as an insular group of people. Unlike programmers who generally only have to interact with people in their industry or with a compiler, testers have to be aware of the "normal" outside world consisting of a diverse set of users. Losing this awareness can be disastrous to a product.

Talk to people outside your sphere about the problems you are having, and look to the fringes of your environment for ideas. Maybe the way the cleaning crew divides the tasks and systematically sweeps through the office at the end of the day can give you inspiration for a new testing technique. Perhaps talking to the receptionist will identify important use cases you hadn't though of before. Approaching things from a different point of view may bring about surprising results.

Bounce these ideas off your significant-other unit, or describe to her a problem you are having. Most of all, use her to force yourself to step back from all the geek adrenaline and jargon of the computing field so you can make your information more accessible to the average human being.