Karen Johnson Q&A
Somewhere along my storytelling journey, I started to notice people using storytelling in very unexpected ways in technical fields — areas like user experience design, agile software development, and software testing. I’m thrilled that Karen N. Johnson, who uses story in software testing, brought her wise observations to the Q&A series. This Q&A with her will appear over the next five days.
Bio: Karen N. Johnson is an independent software test consultant. She is the owner of Software Test Management, Inc. Karen has been involved in software testing for more than two decades.
Karen has extensive test management experience. Her work is often focused on strategic planning for testing on a variety of software projects. Throughout Karen’s career she has gained hands-on experience with many different types of software. For example, she’s worked with banking, manufacturing, and ecommerce software was well as content management systems, contact management systems, medical device software, and business intelligence initiatives.
Karen also teaches classes in software testing. Her classes include how to build a software test strategy and a SQL class for testers. She frequently teaches tutorials as software testing conferences.
Most recently, she has been focused on developing a sense of community for software testers working in the area of regulated software testing. She is the co-founder of the WREST workshop.
She is also currently writing a chapter for a book that will be coming out from O’Reilly publishers slated to be called Beautiful Testing, about testing and how it is beautiful. Beautiful Testing is a collection of chapter-length essays on testing written by a several well-known experts in the field of software testing. The book is expected to be released late in 2009.
Karen is an international keynote speaker. She speaks frequently on software test strategy. She also frequently speaks on storytelling and software testing. She has published numerous articles on software testing as well as recorded webcasts. She also regularly blogs about her practical experiences with software testing.
Q&A with Karen N. Johnson:
Q: In your presentation titled “Learning How to Tell the Story Behind Your Test Results,” you state: “Our purpose is to find the meaning in test results and to be able to tell the story from our analysis in order to bring meaning to data.” How did you initially come across the idea of marrying the fields of software testing and storytelling? What attracted you to storytelling?
A: Have you ever experienced a pull in a certain direction? That’s how I feel about storytelling. It seemed to me like books about storytelling were finding their way into my hands at bookstores. The subject of storytelling kept popping up in front of me from multiple directions. When I first started investigating storytelling it wasn’t conscience, I just followed what interested me. After reading, The Story Factor, I began consciously seeking out information on the topic and was actively working on ways to apply the concept of using stories in my work.
I joined a local storyteller’s guild and started to attend storytelling events. When I met storytellers, especially those who use story combined with business, I began to ask them to tell me their stories about storytelling. One reason I enjoy asking tellers to tell me about using story as opposed to asking for a story is so I gain a deeper sense of how storytelling has integrated itself into who they are. I’m interested in having a discussion on the topic with them, as opposed to them being “on stage” and delivering a rehearsed story. It’s my experience and opinion that strong or perhaps naturally gifted tellers acquire the skill deeply. It becomes part of who they are.
And in fact, I see this same cross over with software testers. Software testers who truly love their work see everything as a testing possibility. If you analyze software all day, it’s nearly impossible to stop being analytical about well nearly everything. Testers gain strong observation skills, the ability to focus deeply and have developed a perpetual sense of curiosity about how things function. How do you turn that mindset off when you’ve been working as a tester for years? The answer might easily be you don’t. You might love what you do and can’t imagine taking anything at face value without wanting to know more.
I have plenty of times in my work that I’m piled deep with reams of information and I have to find ways to sort, compile, discern and then deliver information. I spend time looking for patterns, looking for evidence, always on the prowl as it were to solve issues and I find storytelling is a natural way for me to share my findings with other people.
Storytelling has a strong appeal to me. I love to read and become immersed in a story, to lose sense of time and place. It seems to me, we all pause when someone tells a story. In a technical field such as software testing, perhaps story gives us a chance to put the analytics aside and think about the information in a more reflective way, to take the time to ponder and muse.Q: Your IT career began as a technical writer. To what extent did those writing roots predispose you to incorporating storytelling into software testing?
A: I have a couple of influences in the art of investigation in my background. I was a journalism major in college, and I worked as a reporter for a couple of years. So the tenacity of tracking people down and asking questions and quickly sensing whether someone is a person that I need to gently coax answers and information from versus someone who I need to stand up taller, louder and stronger in order to get information from has become an innate skill. And writing and telling is part of the reporting process.
After working as a reporter, I worked as a tech writer for years on a variety of different types of software. While the image of a tech writer is someone buried in an office cube, I didn’t work the job that way. I spent time talking to the developers, learning the less obvious information about the inner constructs of the applications I was working with. I began to learn that many developers will talk in detail and with pride about what they’ve built. You just have to ask questions in the right way at the right time.
There is a thrill for me in being able to get at least temporarily into the mind of someone else. I like trying to see things the way they do and then take that information and either test software, deliver training, or explain information. I like being the glue on a project by being able to bridge communication between the technical and the business audience. The use of story fits this need.
When I work as an independent software test consultant, I frequently report to senior executives on the current state of a product. I’ve found stories allow me to deliver information in a way that has a better chance of being listened to and consumed then other formats. One thing that I’ve learned from storytellers is that not all stories have to be long tales; a lot of information can be shared in even a one minute or three minute story.Q: What kinds of reactions do you get from audiences and others when you give presentations like “Learning How to Tell the Story Behind Your Test Results?” Are they skeptical? Is it hard for them to wrap their heads around the idea of using storytelling to analyze results?
A: Talking about storytelling in front of a technical audience of software testers is somewhat gutsy. I could run the risk of being seen as fluffy, someone who doesn’t have the technical chops that are necessary in our field. But I think I counter enough of my presentations on storytelling with technical articles, webcasts and blogging. If they look, other software testers can see that I have those credentials as well. In fact, having those credentials may give me a better opportunity to discuss incorporating story as a possibility.
When the pairing of storytelling and software testing is considered, I think it becomes apparent to testers that there are opportunities. Intrigue and agreement have been the most common reactions. I find software testers nodding their heads. After the presentation, they come over and say that they feel they’ve been using elements of story in their work all along. They just never considered delving distinctly into stories and have not previously purposefully tried to use story in their work. The pairing makes sense to them. I’ve had several people approach me in person and in email asking me if I could coach them on where to begin.
I’ve found most of the software testers who talk to me about storytelling are test leads, managers, or directors. These are all people who are in roles where in addition to testing, they need to provide information to business owners or executives. I suspect they’ve found what I have: the need to deliver detailed information in such a way that the information doesn’t get lost with the data. There is a need to deliver detailed technical product findings in a consumable, memorable way without being weighed down with too much information and I think elements of storytelling work.
Q: You wrote in your blog: “I started explicitly seeking books on the subject last summer and by the end of the summer my fledging theory was cementing that storytelling applied to business wasn’t crazy.” Can you share with our readers some of the books you sought out and how they influenced you?
A: I think many things that we do and construct are best when we have a melding of influences. I also think it’s important to recognize and give attribution where appropriate. So let me list a myriad of influences because there was no one book and no one person that brought me to the conclusion of using storytelling with software testing.
In terms of current authors, Annette Simmons and Doug Lipman are two authors whose work I admire. The Story Factor especially made impressions on me due to its countless correlations of story and business.
- The Story Factor by Annette Simmons and Doug Lipman
- Improving Your Storytelling by Doug Lipman
I also found the book Rhetoric by Aristotle to be a great source. My own copy is all marked up and loaded with post-its, which is a sign that a book has brought something to me. I know Aristotle probably sounds stuffy and highfalutin, but it’s not. It’s a very readable book.
My local storyteller’s guild has been an influence as well. Zane Chait and Suzie Garfield are two members of my guild whose storytelling styles and encouragement has helped me. I could sit and listen to Zane for hours and I try to find opportunities to do exactly that.
Could I digress? This is too funny not to share. I can recall the first night I attended my local guild. Zane came right up to me, introduced himself, and welcomed me into the room. I asked him a leading question about how he came to be involved in storytelling. Zane began telling me about his business and his interest in storytelling. I was completely engrossed as he spoke. One of the other guild members had to pipe up and tell us that it was time to get started; “we’re here to tell stories.” Well I wanted to burst out laughing that Zane had been telling me stories since the moment I walked in the room. But I didn’t want to be rude, so we moved into a more formal format for the rest of the evening.
Suzie’s generosity with lending books and information has been helpful as well. Some of the books she’s shared have been Stephen Denning’s work and also Lori Silverman.
My professional colleagues James Bach and Jon Bach are also influencers and encouragers that believe in incorporating storytelling with software testing. We discuss the topic openly and specifically when we’re together at conferences. Also my colleague Mike Kelly has been an encourager sometimes pointing out material he knows will help my pursuit on integrating storytelling with business.
Q: You refer to data visualization and cite Edward Tufte in your presentation. How does the graphical representation of data enhance storytelling regarding test results? Are there people who respond better to this type of visual story than they do to stories told in words?
A: I think there are people who are more visually inclined just as much as there are subjects that may be better told with use of visuals. When I report information to someone, it’s best if I can calibrate my presentation style and tone and length to that person or audience. There are opportunities in software testing to pull in plenty of visuals. Performance testing is one area better suited for graphical interpretation and presentation. Other areas include business intelligence and data mining where pattern detection and trend analysis may be best discovered graphically. Delivering information and findings visually makes sense for those types of problems. I’ve found that story works with visuals, too, so there’s no need to have to choose one over another. I like Tufte’s suggestion that we can deliver information visually and then back up that information with raw data. I think story can work in the same way; we can provide the clarity, tell the story, and then have all our research and legwork available. It’s our data and research that will keep stories from being fables, which is essential in software testing.
Q: If you could share just one piece of advice or wisdom about using story in software testing, what would it be?
A: Experiment and find your own voice. For as certainly as we can bring concepts from other fields into our work, storytelling is another opportunity. Like any skill we pick up — it won’t suit the occasion all the time. There may be situations where storytelling isn’t the best approach but I like to have as many different techniques, ideas and approaches in my skill set as possible. The combination of story and software testing is a great pairing. Try it, experiment. Storytelling is like presenting. When presenting you have to find your own voice, your own style, and your own way of presenting. Storytelling is the same. In order to be authentic you can’t mimic someone else’s style, delivery, tone or mannerisms. You have to find your own way to tell.