Better Software - May 2008 - (Page 20)

Test Connection Out of the Rut by Michael Bolton I’m testing, and I just realized that I’m bored. This is a Bad Thing. I’ll have to do something about it. I’ll sneak a few moments of disposable time, defined as “the time that you can afford to waste without getting into trouble.” No tester that I know of is really supervised every minute of every day. We have moments in which we might try a new test idea, do some side research, look briefly at a different area of the product, or just do something else for a while. If it turns out that I’ve wasted disposable time, it’s OK; by definition I can afford to waste it. But maybe I’ll learn something cool. I ruffle through the piles of paper on my desk, and I find a copy of The New Yorker magazine. The first article that I turn to is a review of a new TV series about psychotherapy [1]. To my surprise and delight, in the very first paragraph, it says, “… boredom isn’t the same thing as being in stasis. Being bored doesn’t mean there’s nothing to do … It means that something big … is keeping us from doing what we want to do, from playing outside, from expressing ourselves, from moving forward.” That reminds me of the cover of a recent Scientific American Mind magazine [2]. More shuffling in the pile, and then there, on the cover: BORED. The cover story says that boredom is triggered by repetition, minute and fragmented tasks, insufficient motivation, the absence of a need for intellectual engagement, and low levels of arousal (the psychologists’ way of saying “the absence of things that wake us up”). These pathologies can build on each other. Without motivation, I lose engagement, and without engagement, motivation becomes more difficult. The article also suggests that repression of a person’s drives and desires leads to aimlessness and disconnection from the task at hand. If our work lacks meaning or purpose over time, we may experience existential boredom or ennui. I often hear from testers who feel this way. Not surprisingly, they report that they are mandated to repeat heavily scripted tests and that they’re not learning, not discovering new problems, and not finding bugs. They don’t feel as though they’re in control of their own testing process. Now I have a question I can ask myself: What can I do to retake control? Here are some heuristics. Trade assignments. When I’m testing, I’m strongly motivated to explore and to exercise my own judgment as to what to do next, based on what I’ve just observed and evaluated. Some people may be more comfortable with a more directed, routine, confirmatory process, and some of that kind of work might be important in certain contexts. On a diversified team, someone else might be a better choice for that kind of work than I am. On a well-managed or self-organizing team, we might be able to trade assignments to play to our strengths. The downside of simply trading off work is that I might deprive myself of an opportunity to learn something valuable. Exploit variation. When I’m feeling bored, I try to change the work in subtle but interesting ways. In a 2005 paper [3], James and Jon Bach identified a number of polarities in exploration—examples include doing vs. describing, careful vs. quick, working with the product vs. working with the developer, design vs. execution, data gathering vs. data analysis, and solo work vs. team effort. When I’m bored, I pause, note whatever approach I’m using at the moment, and try going the other way. The same paper suggests branching and backtracking—deliberately choosing a different path of execution, and then aborting it and backing up several steps. This can be very useful for revealing state-based bugs. The downside of variation is that too much of it might take me off my charter or testing mission. Collaborate. Chatting with a programmer, asking a user about workflows or pitfalls, or pairing with another tester are all ways in which I’ve refocused productively. A conversation—one with a whiteboard is almost always engaging— might allow me to model the system, see new risks, and take a different approach. One risk of collaborating is that, when we’re both looking at the same area, we might lose the opportunity to spread out into testing different areas of the system—but I’ve always been impressed at the way two people see different things when looking at the same screen or whiteboard. Focus on something else. Maybe I’m bored because I’ve been paying attention to one thing too closely, to the same 20 BETTER SOFTWARE MAY 2008 www.StickyMinds.com ISTOCKPHOTO http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - May 2008

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.