Philosophy is one of the driving forces that make me tick, and I certainly think it's both a useful tool for everyone and a worthwhile pursuit in itself. I considered winding up this series of articles with a practical guide on how to bring more philosophy into your testing. However, I know that it doesn't resonate with everybody in quite the same way as it does with me. Some people instead find their joy in art, music, anthropology, or any of dozens of other disciplines.

Moreover, as I did my research for this series of articles, one of the things that struck me was the number of different non-STEM (science, technology, engineering, and math) fields that people leverage for insight into testing. I think we need more of this. I would like to see more people apply their experiences in the arts and social sciences to software testing and development.

The fact that we've labeled software development as "computer science" and "software engineering" tends to limit how we think about it. When we consider approaches to take to a programming or testing problem, we mentally narrow the scope of the ideas we consider to ones that seem technical in nature. By no means do I mean to discount the pivotal roles that these disciplines play in our field. But software development is still a very young field of endeavor that we understand very imperfectly. By steering ourselves away from notions that don't fit our preconceptions of what the field is like, we are likely closing our minds to innovative and possibly even revolutionary ideas.

We often hear creating software likened to building a bridge or a house. I think these metaphors are popular not because they are accurate but because they are reassuring. By classifying programming under the mantle of science or engineering, we hope to make the process of software development perfectly predictable—to make the outcome of every project known at the outset with scientific precision. In doing so, we disregard the fact that progress in science is often non-linear and that cost overruns are a common feature of civil engineering projects as well.

If we dispense with this point of view, then, from what other fields of inquiry does this let us draw insight? In my opinion, the most interesting testing frontiers sit at the intersections of testing and other disciplines, especially those disciplines that engage with our being human, like the humanities and the social sciences. Since testing is a mental activity, psychology is an obvious candidate for insight into how we can test more effectively. Sociology provides tools with which to examine how users, communities, and software teams interact. Realizing that it's not possible to prevent attacks completely, organizations increasingly base their computer security around an economic model—i.e., forcing attackers to spend too much money and effort on a successful attack to make the payoff worth their while. Finally, many people have drawn a link between the creation of software and the tools and methods of older creative disciplines, like music, writing, and the visual arts.

The notion of drawing on non-STEM disciplines may sound far-fetched, but many well-known software professionals have already embraced it. For instance, Adam Goucher nominated Steal Like An Artist as his testing book of 2012 in a blog post in which he exhorts the value of reading non-testing books to become a better tester. Chris McMahon argues that creating software is an act of performance, not of engineering. Marlena Compton draws parallels between critiquing art and testing software, as well as between communicating the behavior of a piece of software and communicating what a piece of art is like. Richard P. Gabriel went so far as to say that effective programming skills could best be cultivated like effective writing skills and proposed a program for a master of fine arts in software degree. Finally, at the 2012 STAREAST conference, Michael Bolton gave a keynote on how the social sciences (including anthropology, sociology, and journalism) can influence our testing, and Zeger van Hese presented a session entitled Artful Testing: Learning from the Arts.

So, how do we draw insights from other areas of human experience into our work? I'm not certain that there is a way to do this that's applicable to every tester in every circumstance. Everyone's life experience is different, as is the diversity of fields each person has been exposed to. But, I believe a few guidelines can help get us thinking in the right direction.

Keep an open mind. Don't dismiss things out of hand, even if they at first appear very dissimilar from your work. Improv comedy may not remind you of your workplace, but it can teach a lot about reacting to unexpected changes—like changing requirements—quickly, gracefully, and constructively.

Look for connections. Focus on similarities and possibilities before considering differences.

Cooking and software testing might not seem to have much in common until you look at the parallels between writing out a recipe that's easy to follow and describing a bug so that it's easy to reproduce.

Start with what you have. You're probably already familiar with a number of areas outside of software. Use this valuable expertise to full effect.

Expand your horizons. Consider taking on a new endeavor or learning about different fields by reading books, watching presentations, or listening to podcasts. Deciding to take up the viola in my mid-30s was perhaps an unusual choice, but it has taught me a great deal about how practice, confidence, and relaxation show through in the products of one's work.

Be willing to challenge assumptions. This includes both your own assumptions and everybody else's. Part of challenging assumptions is being aware that one is making them in the first place. Learning a different language or spending time in a different culture quickly drives home how many of the mundane things we take for granted are arbitrary cultural or linguistic norms.

Do not fall for analogies. Realize that they never represent the thing described with complete accuracy, and know when they have gone too far. Alfred Korzybski said, "The map is not the territory." To put it another way, "Don't eat the menu."

Software development is still a very young field, and I think it behoves us to cast the net as wide as possible when looking for potential improvements. So, I will end with an exhortation. If you have a hobby or an area of interest outside the hard sciences, put it to use. If you don't, consider taking up something. See what insights you can bring over into your software work. Find them. Apply them. Write about your experience. Communicate them to the rest of us so that we can try to improve our understanding of our discipline together.