By Katrina Ohlemacher
Douglas Adams once said, “Writing is easy. You only need to stare at a piece of blank paper until a drop of blood forms on your forehead.” While it’s true that it can be difficult to transfer thoughts from your brain to the page (see the photo above – those are real stickies on my monitor right now), I’ve found that my history as a writer and editor provides some unexpected benefits when it comes to software testing.
Some people are visual thinkers, and some people are verbal thinkers. I’ve always been a writer and verbal/narrative thinker. I don’t picture things in my mind’s eye easily, but I can write down a story about what I’m doing in a snap. That has its pros and cons – sometimes it’s hard for me to understand how complex systems chain together, but it’s useful when I’m learning about how an app works and what I think it should or shouldn’t do.
I like to take notes as I test, because it helps me go back and replicate exactly what I was doing in the event I discover a bug. Some people keep bare-bones notes:
• Log in • Enter data • Click submit • Receive 400 error
I prefer to tell myself a story while I’m working. Here’s an excerpt of my notes from a recent exercise in testing a website that automatically generates bibliography entries in a variety of styles:
• Checked the main page instructions and read the FAQ. • Adding a book by ISBN, an article by DOI, and a tweet by URL, because I'm curious about whether it can do a bibliography entry for a tweet. (Huh. It can!) • Creating a link to this version of the bibliography. Clicked “Create” and then “View.” That wasn’t what I expected. Thought I was going to view a URL. • Clicked the copy icon next to the article I added by DOI. I don’t really understand what any of this does. I clicked “Omit author” because I think that would change something in an inline citation if I had already referenced the author in that sentence. Whoa, the whole modal is gone. That seems buggy.
When I go back to review my notes, it’s like I’m having a little conversation with my past self. If I have notes that help me remember how I felt about the bug when I found it and why I took the action I took, I’m likely to remember more details about what happened. Writing in a style I’d like to read later makes it easier for me to follow my notes and see what I was learning about the product and when.
This technique also helps me write better bug reports. It’s fairly easy to transfer my notes into a bug report, clean them up a little (emotional commentary might be helpful for me, but developers don’t necessarily need that to reproduce a bug), and submit the report without the hassle of going back to describe every step in detail — it’s already done in my notes.
Thinking narratively about the app lets me put user flows in perspective — I’m telling the story of how someone will use the product, and that puts me closer to the mindset of an end user rather than the mindset of someone who’s spent weeks looking at the same few screens. If I can go back and picture my own journey through the app, it’s easier to imagine the experience of someone using the product for the first time. That helps me imagine the things they might do “wrong” as they start out. (But if it’s what a user is likely to do, is it really wrong? Maybe it’s the app that’s wrong. Mind. Blown.)
I can also pass on my notes to almost anyone, and they can see exactly what situations I was in while testing. If I use a narrative style and descriptive language, it helps them understand the severity of an issue and how it made me feel as a user. Plus, it’s fun — telling a story connects you to the person reading your notes, and I feel like they get to know me better when they see how I think. That’s helpful for people who have to work closely together on a project for a long time.
This isn’t to say that narrative notes and a narrative mindset are the only way to test. I know testers who do great things with, say, bare-bones notes and an elaborate mind map. Or they may draw diagrams for themselves as they go, or make detailed outlines that would make a middle school teacher weep with joy. Use what’s best for you. But telling a story is what works for me, and if you’re also a storyteller at heart, I bet these techniques will help you on your testing journey.
Katrina Ohlemacher is a traveler, a writer, a procrastinator, and any number of other nouns. Hers is a tale as old as time: After working at newspapers and nuclear power plants, she made the leap into Quality Assurance by quitting her job and attending a boot camp with no back-up plan. But, as Hunter S. Thompson says, God watches out for fools and sportswriters, and she eventually landed at Detroit Labs. She would like to note that the Oxford comma has been added to this bio over her vehement protests.
If you’re looking to network with other devs, join our CoLabs Community and we’ll get you connected at our next meetup!