old-blogs/new-testing-blog/Fear As A Heuristic For Testing.md

# Fear As A Heuristic For Testing

Second only to critical thinking and empiricism, *self-awareness* is the single most useful and important tool in the toolbox of a tester.

After absorbing experiential input from any given event, the emotional data that is subsequently returned from within is a crucial piece of evidence necessary for interpreting and understanding the event, and for deciding how you want to respond to that event.

This may seem, at first, like nothing more than a complicated way of saying "action = reaction". But that's not quite what I mean. This simplistic restatement describes exactly how most people regard their emotional lives: on the periphery of consciousness, autonomously driving preconditioned behaviors, accumulated in childhood and early adulthood.

What I am suggesting, instead, is that we can retrain ourselves, to consciously *observe* and choose an appropriate response, rather than merely reacting. While I'm not a subscriber to either Stoicism or Buddhism, both philosophies offer a notion of "mindfulness" that closely describes what I want to encourage.

As technicians, and testers, if we can get to a point where we are able to "inspect" *ourselves*, as we are exploring some new build, or product, or technology, additional insights become possible. 

There is one emotion that I find especially important to this task: *Fear*. When this emotion occurs in the wild, it instinctively drives avoidance behaviors. The behaviors designed to keep you from being mauled by a tiger, or bitten by a snake. But in the context of testing a software project, these behaviors are maladaptive.

Among the various "threats" we sense in our day-to-day lives as testers and technicians, are that of unfamiliar technologies, or tools. And the anxiety that comes to the surface around these things can be intense. Particularly in situations where we are surrounded by other very smart folks, whose judgments of us may affect our careers.

#### Turn In The Direction Of The Skid

For a large part of my early career I was plagued with a problem that I mistakenly thought only I had. I was terrified that eventually, inevitably, someone was going to "find me out"; I was going to be discovered as an incompetent who'd somehow managed to sneak past every interviewer in the company I happend to be working for. 

In response to this fear, I withrew from any opportunity that might put me in a situation that stretched the limits of what I knew, or what I was skilled at -- in other words, anything that might expose me as a fraud. For a long time, this trapped me in a box of narrow possibility and narrow value. Withdrawal was perversely creating exactly the situation I incorrectly feared I was in to begin with. 

Reversing this process was difficult, and the details of that journey are the topic for a different blog post at a different time. But for the purposes of this discussion, it's important to note that the work began with a key realization: I wasn't wrong about not knowing things. I was wrong to think that I was the only one who didn't. And even more wrong to think that I was the only one who was *afraid to admit it* (in fact, it turns out this is a [common psychological phenomenon](1)).

What's more, when I started paying attention to the folks who seemed to excel where I could not, I noticed they were not the ones who *already knew* what they were doing. They were the ones asking questions, reading books, and experimenting. In otherwords, they were the ones who seemed unafraid to admit they didn't know. 

In fact, it turns out, they still feared that admission as much as I did. But they did something different with that fear. Rather than using it to avoid judgment, they were using it to point them in the direction of *new knowledge*. They were willing to risk calling the bluff of the fear, for the potential benefit of new opportunities. 

#### Into The Lion's Den

This is a lesson that is very hard won, but also very much needed in the testing community. Not only for career potential, but also for the reward it offers in day-to-day testing itself. The more risks you're willing to take, the more chance you have at discovering new bugs and potential usability problems with the product you're testing.

I have experienced this many times over the last ten years or so. Every job I've had, I've been faced with the terrifying realization that I had no idea what I was looking at, or how I was going to test it. But instead of withdrawing, as I would have in my old life, I dove in head first. And in doing so, I was able to dramatically increase the value I had to offer to my employers, as well as dramatically improving the quality of the products I was helping to test:

* Finding flaws in python SQLAlchemy calls to an Oracle database, that threatened the integrity of data that belonged to many large institutional clients. 

* Working side-by-side with .Net developers to provide C# unit test coverage on several key pieces of a highly profitable enterprise elearning product. 

* Identifying critical problems with key functionality like LDAP authentication, compatibility issues in a supported database platform, and feature authorization leaks, in a product meant to be used by developers in an enterprise environment.

I point these examples out especially, not because I want to demonstrate how much I know, but rather, because these are dramatic examples of how much I *did not know*. They represent moments of accute fear for me. Moments that required me to notice that fear of the unknown, of "being found out", of "appearing incompetent", and to decide how I wanted to respond to it. 

#### Doing The Work

What I decided to do, was to emulate the behavior of those I'd noticed in the past, who were excelling: admit my knowledge gap; ask for help; and then research, read, and experiment on my own. And in doing so, I've acquired skills I didn't have before. And I was able to make that choice, because I've been slowly practicing the skill of "inspecting" myself, when I inspect the software I'm testing.

Admittedly, it's not easy to aquire the mental habits necessary to be able to face that fear, and make that decision consciously. There are many [places](2) to go on the internet to find ad hoc [advice](3) on how to turn fear into a personal asset. But on this front, I'd suggest considering some professional advice, from a good cognitive therapist. As with tech questions, it can be equally as useful to admit there's a lot about ourselves that we don't know, either.

From my own testing experience, I can offer three rough ideas that you might find helpful for kick-starting the process: 

First, when you're surveying a new application, all of its components, and its infrastructure, note down when you feel least comfortable. What were you looking at when you first started feeling uncomfortable? Are there any common areas where you feel least comfortable? Are there any areas you find yourself impulsively ignoring or avoiding? All of these areas might be candidates for further investigation. 

Second, when you are in morning standup or in feature design or sprint planning sessions, do you ever find yourself completely lost or afraid to admit to your devs that you don't know what they're talking about? This might be a good opportunity to take one of them aside afterward, and ask for some time to go over the technical details, or to ask for a good resource that you can pursue.

Third, and most important: Have you noticed things landing in user support tickets or bug reports that deal with aspects of the product that you didn't realize you were unfamiliar with, or have been unable to test properly because of something you've been avoiding about it? This might be something you'll put at the top of your "must learn" list.

#### Conclusion

It seems to me, that emotional evidence is an untapped area of exploration, in testing. This post focused entirely on fear, but there are probably other emotions that could be identified as useful signals of potential improvement in the way we work, or of potential sources of new knowledge, or quality insights. This post obviously isn’t a comprehensive look at fear. There’s a lot of room for discussion on this topic alone. But hopefully, this is enough to get people thinking about the subject.
 

 [1]: https://en.wikipedia.org/wiki/Impostor_syndrome
 [2]: http://www.bulletproofmusician.com/how-to-make-performance-anxiety-an-asset-instead-of-a-liability/
 [3]: http://hearingtheheartbeat.com/2013/06/17/how-to-turn-fear-into-an-asset/