Potty training

29 Wednesday Jan 2014

Posted by claire in Experiences, Experiments, Protip, Soft Skills, Software Testing Club Atlanta, Testing Games, Training

≈ 1 Comment

My first experience with testing games was back at my first testing conference when Michael Bolton gave me a testing challenge at lunch: a rubber ball. I didn’t know what I was getting into, but I knew I loved games. And that is a key aspect of how games help us to learn: getting past our resistance by promising us fun. Since software testing is a complex mental activity, exercising our minds is an important part of improving our work.

After attending several testing conferences, I can safely say one of my favorite aspects of these gatherings is evenings filed with testing games. (That is, games for testers, not testing video games.) Whether you’re rolling the dice (more, spoilers), deducing when a pen is not a pen, building a tower of pyramids, or shouting out “Set!” as you casually wander past, testers love a challenge.

So it was no surprise that John had his game bag already on the table when I arrived for the STC ATL holiday meetup. What I didn’t expect was Disruptus, a new-to-me game. He explained for a few minutes and then we jumped right in to playing. Almost immediately, I flipped over a card with an image of a toilet and the improve card:

Add or change 1 or more elements depicted in the card to improve the object or idea.

TMI

Skip this TMI stuff!

Since we are currently potty training at our house, this was a particularly relevant subject for me. I started rattling off ideas as they came to mind. John stopped me and said that I wasn’t coming up with new ideas but instead listing things that had already been done. While I agreed, I found that saying each of the knowns out loud helped me to clear my head for the next idea to come along.

Ideas that sprang to mind:

You know, for kids

toilet seat lock for babies just learning to walk
toddler height toilet
step stool for standing toilet training (boys)
separate lightweight plastic toddler toilet – could be portable
folding travel toilet seat for toddler on-the-go
built-in potty seat for toddler years that is easily removed for cleaning
moveable toddler handled seat for better balance
splash guard for boys potty training
tiny plastic urinal – I’d seen one once at a kids consignment sale
toilet target for potty training boys
soft-close lid that doesn’t slam down on little fingers
tie-in to children’s book/video for better motivating child (i.e. matches picture) – with audio/musical accompaniment for better motivating child
toilet with book rack attachment – also good for adults!
tie-in to popular children’s character for better motivating child
And of course Pinterest is awash in toilet training ideas…

Adult toilets

Dune’s Fremen stillsuit (okay, so that’s not real…)
water-conserving toilets – high efficiency, multi-flush options
recycling water from washing hands for next flush
elevated tank to use gravity for flushing
recently read an article about posture and advantage of raising feet using step-stool
bidet attachment that I saw at a co-working space
soft seat vs. hard seat
toilet scent spray that a friend mentioned to me & has ridiculous commercial
elongated seat
elevated seat for elderly with limited range of motion – vs. seat riser/handles
foot pedal to raise/lower the lid without using hands
putting the seat back down in the first place
self-cleaning – or at least those tablet attachments
germ resistant surface
I’d once seen a toilet with an automated toilet-seat-cover replacement system
I’d seen more exotic toilet options in a local farmer’s market store
a friend explained the composting toilet to me
chemical toilet/waterless toilet for big events like outdoor concerts
urinals – I’d seen a public outdoor urinal in Amsterdam that was just two large crosspieces for minimal privacy
device allowing women to stand for urination – thanks, Twitter!
chamberpots
outhouses

Things I’d never heard of

Glow-in-the-dark toilet seat – this would be a big hit with the kids!
Squat toilets
proximity sensor
toilet seat warmer – including power saving mode!
electric lifting seats for the elderly
female urinal
sound cloaking
toilet slippers
pretty much anything shown in Cars 2 when Mater visits the restroom

Motivation

Of course, it wasn’t until much later (esprit d’escalier) that the thing I really wanted to improve came to mind: I hate toilet auto-flush algorithms. As a happy user of toilet seat covers in public restrooms, I always feel concern about whether I’ll have to contend with a particularly sensitive hands-free toilet. Despite my years of experience, I have not yet mastered the art of evading the motion sensor while placing the toilet seat cover.

I would love to rewrite the algorithm to some set pattern of motions that would distinguish between someone leaning toward the seat to place a liner – and so avoid germs – and someone leaving the stall having completed her errand. Even clap-on, clap-off would be preferable to spray in the face from an unexpected flush.

Protip : My husband takes a 2 foot length of toilet paper and blindfolds the sensor. Manual flush never felt so good.

Training through play

So now that you made it past TMI, let’s get back to the notion of testing games for training testers. Do testing games help testers learn how to test? Many testers are making an argument for this.

John Stevenson is one of them. He uses Disruptus to encourage disruptive thinking that leads to innovation – in testing. Create, Improve, Transform, Disrupt: these 4 approaches are important when designing and executing tests. Finding new ways to remix our tests helps us to focus on things that matter but to approach them in a new way, extending our coverage of various paths and potential usage patterns. My experience with only a few turns of this game left me invigorated and encouraged to try new things at work.

How have you used games to learn about testing?

Sketching for fun and profit

17 Friday Jan 2014

Posted by claire in Agile2013, Approaches, Experiences, Experiments, Soft Skills, Speaking, Training, User Experience, Visualization

≈ 1 Comment

As I recently wrote in Better Software magazine, I tend toward visualizing information. While this does not mean I skimp on words – as anyone who has been near me for 15 minutes can attest – it does mean that I think more clearly when I have a whiteboard in front of me and a chisel tip marker in my hand.

Ode to whiteboards

“@aclairefication: No sticky notes. No whiteboards. #FiveWordTechHorrors” this happened to me last week.

— James Grenning (@jwgrenning) December 11, 2013

One Christmas gifts my husband installed a wall of whiteboards in our home for the children to draw and scribble. The children loved it and happily covered it with unintelligible childhood graffiti. As it turned out, this blank wall was a greater gift to me. When I was preparing to present at conferences in 2013, I was feeling quite blocked in writing proposals and producing presentation materials until I relaxed and just let myself have time with my home whiteboard.

I hadn’t realized how much I missed having a large expanse to fill with thoughts as they came spilling out. At my first testing job, my XP development team installed a wall of whiteboard for just this sort of thing, removing barriers to collaboration by having enough space for any conversation the team needed to have. Of course, some corners were dominated by persistent big visible charts but those lasted only as long as they were needed. Yes, I was spoiled.

I decided to keep my presentations simple and sketched the images I wanted to have in my slides on this wall. It turns out taking well lit pictures of whiteboards without glare is sufficiently difficult that there are apps for that. Go figure!

Takeaways

I also realized that I would be in a fix at the conference if I didn’t have a whiteboard handy, so I scoured the internet looking for portable options. It just so happened that one of my favorite nerdy websites was advertising a foldable pocket whiteboard. One look and I was in love. I was able to easily take notes in any way I saw fit and at a scale that pleased me, not being limited to eight and a half by eleven or whatever dimensions a digital application considered adequate.

In my day-long tutorial preceding CAST 2013, on a team with people I’d never met, I wasn’t sure how to begin solving the problem, but the casualness of a portable whiteboard that could be unfolded, scribbled on, wiped away, and stowed out of the way was definitely an asset to establishing good communication from the beginning.

It also came in handy when I was able to snag a table at one of the Agile2013 social events to catch up with a speaker whose talk I had missed. He liked it so much, he bought three. Subsequently, another friend from the conference asked whether that would be a good speaker gift and I heartily assented. Now I’m wondering whether this company pays for referrals. 🙂

Drawing pictures at work? Really!

At Agile2013, in his presentation Sketch you can!, Jeremy Kriegel explained using graphic facilitation to craft meetings that better involve attendees. People can focus on visuals easily and suggest improvements. This sketching is a combination of note taking and wire framing, which is something user experience (UX) folks do routinely as part of their work. He describes trading quality of the drawing for speed in order to keep the focus on communication, then enhancing the drawing later. The focus is on the need people are trying to satisfy and understanding the context of that need.

By sharing in a concrete way, you can validate precise language and discover where meeting participants are not agreeing. The result is a public record of the conversation that can be shared. (I’ve been known to take many many pictures of whiteboards in my day.) However, the communication is more important than the deliverable, which helped to free me of my concerns about how much artistic talent I have. I felt comfortable improvising and the sketching was a sort of performance, although in the class we were not standing up in front of a group.

Earlier today, I was having a conversation with a colleague at a whiteboard and sketching the interacting parts of the problem we are testing was very helpful for focusing the conversation and revealing areas that we needed to investigate. I’m definitely a fan of drawing pictures at work and I appreciate Jeremy’s encouragement.

Sketchy people

Periodically, I rediscover Gaping Void and wallow in the talent and inspiration of these images. My most recent visit followed a tweet to his blog on new year inspiration:

I guess my “mountain” was drawing cartoons (like the cartoon at the top rightfully indicates), although it took me DECADES to find that out. – Hugh MacLeod

However, I was so drawn to his live sketching videos that I decided to give it a whirl. Not sure where to begin, I snagged a photo of my 95-year-old grandmother off a family member’s Facebook and took a shot at digital sketching. I’m pretty pleased with the result. It’s not my best effort and I’m not worried about that because it was so much fun to try.

When I’m so busy that I don’t have time to blog or read a book or play a board game, I still have time to sketch something out, however crudely drawn the result might be. I know I won’t turn into an Andrea Zuill overnight, so I keep at it a little at a time.

I’m finding that sketching on digital photos or enhancing existing images (so far no original memes!) is much much easier than starting from nothing, so that’s kind of my thing at the moment, but I’m finding the courage to stretch a bit more into original composition. We’ll see if anything comes of it. For now, it gives me something creative to do that personalizes my slides a bit more.

How do you use sketching for fun or profit?

Fresh Perspective

17 Thursday Oct 2013

Posted by claire in CAST 2013, ISST, Training, User Experience

≈ Leave a Comment

I can’t remember what it was like to start working as a tester. Ten years later, the only impression I have left of that time is voracious learning. So yesterday’s debut of the ISST webinar series focusing on the first 2 weeks on the job as a tester was a good refresher for me.

Ben Kelly gave a description of two distinct new testers and their experiences of adjusting to the expectations for testers. This reminded me of Pradeep’s talk at CAST this year about his “baby shark” new testing trainees. I suppose that shouldn’t surprise me since they’re among the founding members of ISST.

Both emphasized that novices have an advantage: ignorance. While that doesn’t sound like a very positive description, one you might not want to claim for yourself, it resonates with me. Most of my professional progress has been made asking the dumb questions that filled in my ignorance, pointing me in the right direction rather than remaining stagnant.

But ignorance is not enough, merely lacking information one stagnates. Curiosity turns ignorance into action, transforming it into a powerful tool. (I think this is what people refer to as beginner’s mind, though I haven’t studied that concept myself.) Pradeep explains that newbies have a tactical advantage in not having been misled yet. Ben reminds us that while asking questions seems so simple it’s actually deep exploration of context, not just about business content but also about team expectations.

When Pradeep’s freshers (I think I’m using that right, right??) go out into the world to help start-ups with testing, they’re learning multiple contexts. This adds a bit of complexity to the already daunting task of acquiring testing skills. Sounds intimidating, doesn’t it? While these testers get on-the-job training, the start-ups experience the value of a context-driven testing approach focused on providing business value, which shifts from business to business.

Ben and Pradeep emphatically drilled us on providing information in the way the consumers can understand. Knowing that they have multiple audiences, testers must be excellent communicators. As an intuitive person, this intimidates me – and it sounds like other empathic testers may have similar trouble. I took my first stab at messaging about testing with members of my product team since that was most familiar to me. However, test reporting above the product team hasn’t been a big part of my career so far. My primary approach there has been getting to know the end users.

I know this webinar was aimed at less experienced testers, but I’m reminded that I could use a fresh approach myself. Like some (formal) practice in session debrief? Joining forces with sales for product demos? What approaches keep test reporting fresh for you?

Image credit

Sick and Tired

03 Thursday Oct 2013

Posted by claire in Experiments, Lean Coffee, Speaking, STARWest 2013, Training

≈ 1 Comment

Brain_Drain
On the first full day of STARWest 2013, I ended up at home with my sick son. (Stomach bug. Boo.) Fortunately, most of the excitement had passed by morning and the day turned out to be blessedly restful, which was essential for this sleepy mom keeping vigil.

We rolled out of bed and sat on the couch watching a cartoon in companionable silence while I poked about on Twitter to find information on the morning’s Lean Coffee to attempt virtual attendance. Since it turned out to be a Google Hangout, my son became much more interested in paying attention, selecting various digital accessories for me – much to the amusement of the other attendees. (Son’s first Lean Coffee? Check. Wearing a digital monocle? Check. Winning at parenting? Check!)

As with any remote conferencing system I’ve ever used, the setup and logistics had their challenges, but I was happy to be included in the event in this small way. The one topic that I could clearly hear concerned sharing conference learnings after returning home.

The classic: presentation to the team.

Many people have blogged about writing – or presenting – a great trip report. Usually these start out with advice for writing your conference attendance proposal to include some language about teaching what you learn, perhaps at the prompting of your boss. At the conference, you take great notes, perhaps even writing up your report during a layover on the way home. Upon your return to the real world, still on a conference high, you set out the conquer your problems with the grand visions of a better work life only to confront business as usual… which you will somehow overcome in a single hour or two of lecturing? It’s a rude awakening. Somehow the top-down decision that the team will learn – from you. right now. – isn’t quite working out. So how do you overcome the resistance to change and really bring home useful lessons?

The subtle: solo experiments as exemplars.

A tactic I prefer is coming home with a list of things to try “on Monday” when I’m back in the office. I think of this as a series of small experiments. Matt suggests keeping these experiments isolated to your day-to-day work in order to improve results without running into the dreaded inertia of the system. As they say, big wheels turn slowly. I can certainly see his argument there since past attempts to suggest alternate approaches that radically changed others’ tasks haven’t really worked out for me. I feel a lot of ownership of my experiments and the experiences have opened up my thinking to additional new techniques, approaches, and strategies. Is your pen mightier than the the sword? Will your report really sway your audience? I certainly have tried this option in the past, but teams may find that approach tired, just one more meeting to attend.

How to bring conference learning back to the team? #leancoffee #starwest @mheusser does experiments solo. @g33klady is doing a presentation

— Claire Moss (@aclairefication) October 2, 2013

The novel: long and drawn out denouement.

The new shiny approach that I’m currently tackling is making connections among different presentations and topics to connect them in ways that seem particularly relevant to my work team’s context. My current experiment is a series of smaller presentations, complete with food and succinct snippets (the TL;DR) in emails that will link to blog posts (the deets). Gradual exposure seems better than bombarding a team with new information in a one-time brain dump. I just hope no one gets sick of my weekly missives!

I’m putting together Lunch-n-Learn presentations and weekly email/blogs to distribute. Less info dump, more learning #leancoffee #starwest

— Claire Moss (@aclairefication) October 2, 2013

As the conference delegates adjourned to attend the regular sessions, I remained sitting with my son. It might have been the exhaustion talking, but when he asked me for my mobile phone I gave in. Within minutes, he found an odd interaction (bug?) in the mobile Hangouts app and shortly afterward froze Angry Birds with a feathered missile in mid-arc. Natural born tester, I tell ya. Making his momma so proud it was easy to forget the sickness and fatigue.

Update from this morning’s Lean Coffee!

Going to use #LeanCoffee as the way to share what I’ve learned at #starwest with my team

— Hilary aka H-Bomb (@g33klady) October 3, 2013

Image source

Story Time!

16 Monday Sep 2013

Posted by claire in Acceptance Criteria, Agile2013, Approaches, Context, Experiences, Experiments, Metrics, Personas, Publications, Retrospective, Speaking, Training

≈ Leave a Comment

As Agile2013 considers itself a best in class kind of conference “designed to provide all Agile Team Members, Developers, Managers and Executives with proven, practical knowledge”, the track committees select from a large pool of applicants and prefer vetted content that has worked its way up from local meetings to conferences. I have only one talk that fits this criteria since I presented Big Visible Testing as an emerging topic at CAST 2012. I developed several versions of this talk subsequent to that event and doing so had given me confidence that I would be able to provide valuable information in the time allotted and still leave enough time for attendees to ask questions and to give feedback on what information resonated with them.

I worked to carefully craft this proposal for the experience reports track, knowing that if I were selected that I would have a formal IEEE-style paper to write. Fortunately, my talk made the cut and I began the writing process with my intrepid “shepherd” Nanette Brown. I wasn’t sure where to begin with writing a formal paper, but Nanette encouraged me to simply begin to tell the story and worry about the formatting later. This proved to be wise advice since telling a compelling story is the most important task. Harkening back to my high school and early college papers, I found myself wading through different but largely similar drafts of my story. I experimented with choosing a different starting point for the paper that I ultimately discarded, but it had served its purpose in breaking through my writer’s block. Focusing on how the story would be valuable to my readers helped to hone in on sequencing and language selection. Once I had the prose sorted out, I began to shape the layout according to the publication standards and decided to include photographs from my presentation – the story is about big visible charts after all!

Investing sufficient time in the formal paper made preparing the presentation more about strong simple visuals. I have discovered my own interest in information visualization so prototyping different slide possibilities and testing them out with colleagues was (mostly) fun. I’m still not quitting my day job to go into slide deck production. Sorry to disappoint!

Performance anxiety

Despite all of this preparation, I couldn’t sit still at dinner the night before my presentation and barely slept that night. I woke before the sunrise and tried to school my mind to be calm, cool, and collected while the butterflies in my stomach were trying to escape. This was definitely the most challenging work of presenting!

As a first time speaker, I didn’t know what to expect, so I set my talk’s acceptance criteria as a rather low bar:

Someone shows up
No one hates it enough to leave a red card as feedback

When I walked into my room in the conference center, a lone Agile2013 attendee was waiting for me. Having him ready to go encouraged me to say hello to each of the people who came to my presentation, which in turn changed the people in the room from a terrifying Audience into many friends, both new and old. I think I managed not to speed through my slides despite my tendency to chatter when I’m nervous. I couldn’t stay trapped behind my podium and walked around to interact with my slides and to involve my audience more in the conversation. Sadly, I can’t share my energy with you since I forgot to record it. Oh well. Next time!

The vanity metrics

At 10 minutes into the presentation, 50 people had come to hear me speak and at 60 minutes I had somehow gained another 7 to end at 57 people. Thanks so much for your kind attention! I hope I made it worth your while…
43 people stopped to give me the simple good-indifferent-bad feedback of the color-coded cards (which I liked as a simple vote about a presentation) and I received 37 green cards and 6 yellow – with no red cards! Whoo hoo!

Words of Encouragement

Two people kindly wrote out specific feedback for me and I want to share that with you in detail, hoping to elicit some late feedback from attendees who might like to share at this point (Agree or disagree, I want to hear from you!)

Feedback Card #1:
– Best session so far!
– Great presenter – great information – great facilitator
– Would like to see future sessions by this speaker

Feedback Card #2:
Great Talk – speaker very endearing, Her passion for the subject matter is obvious.
A fresh perspective of how Developers and Testers should interact.
Should find ways to engage the audience

Someone else got a kick out of my saying, “I’m serious about my stickies.” and left their notes behind on the table after leaving. So thanks for sharing that. 🙂

One friend spoke to me afterward with some helpful feedback about word choice and non-native English speakers. When I was writing my talk, I was trying to focus on people who would be likely audience members, but I had not considered that aspect of the Agile2013 crowd. Since I was simply speaking off the cuff, I ended up using some words that would have fit in at our dinner table growing up but that would make for tougher translation. And yet, I got some wonderful feedback from Hiroyuki Ito about the “kaizen” he said I made. I can’t read it directly, but Google Translate assures me it’s good stuff. 🙂

uneasy truce

Finally, I discovered that my relationship with a linear slide deck is not a comfortable one. I wanted to be flexible in referencing each of the slides and having to sequence them hampered my ability to respond easily with visuals when discussing questions or improvising during my talk. I haven’t experimented with other presentation options, but I hope there’s an easy solution out there.

Image Credit

Big Visible Testing (Full Length) from Claire Moss

Big Visible Testing Full Length

19 Monday Aug 2013

Posted by claire in Agile, Agile2013, Approaches, Context, Experiences, Experiments, Personas, Publications, Speaking, Training, User Experience

≈ 2 Comments

Here are the slides from my full length Big Visible Testing talk, presented at Agile2013 in Nashville, TN on August 6, 2013.

Big Visible Testing (Full Length) from Claire Moss

My experience report paper will be published by the Agile Alliance under the conferences archive as part of the proceedings of the Agile2013 conference. You can also download the PDF here: ClaireMoss-BigVisibleTesting-Agile2013

During the year and a half of experimentation that included the big visible charts that are included in this slide deck, I read over the following resources, only some of which would easily fit into the IEEE format. This is the full bibliography of my research, as far as I have been able to track down my sources. (At the time, I wasn’t expecting to cite them for anyone else, so I probably didn’t bookmark everything I read.) I hope the following links will prove helpful to you in developing your own big visible charts. Let me know how it goes! And please share any sources that you find helpful. I’m always looking for new inspiration.

REFERENCES

My first dev team was an XP dev team that dogfooded our own digital signage product to display success/failure for the thousands of unit tests in the suite (i.e. single flag for whole suite red/green).
Other eXtreme Programming big visible charts

Extreme Feedback Devices summary – I loved this team’s “feel-around” approach to feedback!

Alistair Cockburn coined information radiator
Alistair Cockburn’s burn charts (burn up vs burn down)
Information radiator flash card
More information radiator stuff

Lisa Crispin’s whole team approach includes Big Visible Charts
Energized Work site map backlog
More from Lisa Crispin’s tour of Energized Work

Heatmaps (from code analysis)

Paul Holland’s Exploratory Testing charter Kanban board
Lanette Creamer and Matt Barcomb gave a presentation that included ET charter management in big visible charts; podcast preview of their session

Visualizing above the product team
Including faces of people/profiles in the big visible charts
I can’t remember whether I’d see this one at the time or not… it might have been something I discovered after my time on the team mentioned in my presentation: Visual management for agile teams

New inspiration

Although the above resources were all I knew at the time I began my experiments, as I prepared my IEEE paper for the Agile2013 conference proceedings, I was tracking down my sources and came across these other relevant pages & posts that have given me some great ideas of things to try next!

Gojko Adzic’s visualizing quality

Michael Bolton’s mind-maps

I like this greyhound chasing the rabbit decoy visualization Alistair made
Alistair’s projects (radiating)
Alistair’s collaboration cards

Lego representation of bugs

Other cool extreme feedback devices:

bat signal (as a Batman nerd, I heartily approve!)
bear lamp
traffic light

Clothesline wallboard contest entry – as an avid crafter, I adore this one!
Wallboard contest results

After some discussion in my session about suggesting solutions for distributed teams, I was looking for some digital implementations of big visible charts, but I don’t know how these would work out for you.

Atlassian on information radiators for extreme feedback (with broken image links – sad!)
Atlassian on information radiators
Greenhopper (Jira plugin) wallboard
More on Jira Wallboard

Countdown to Agile2013!

02 Friday Aug 2013

Posted by claire in Agile2013, Experiences, Speaking, Training

≈ Leave a Comment

I’m so excited about next week that I’m re-reading the schedule for next week with great anticipation (on a Friday evening. Yeah, I’m a big nerd. It’s cool.)

So in celebration, I’m counting down to my first full-length talk at the conference! See you there!

weeks

-51

-2

days

-3

hours

-1

minutes

-3

-6

seconds

-4

-2

I’m on stage right now. Come join me![/tminus]

See you soon

30 Thursday May 2013

Posted by claire in Agile, Agile2013, CAST 2013, Experiences, Exploratory Testing, Scrum, Speaking, Training

≈ Leave a Comment

I’m excited to announce that I will be speaking at two conferences this year!

If you’re on your way to Agile2013 in Nashville in August, please stop by my full-length Big Visible Testing session in the experience report track. I simply didn’t have enough time to tell you all the cool stuff in my CAST 2012 emerging topic.
If you’re excited about trying exploratory testing with some in-person coaching, Matt Heusser and I will be there for you.
Or catch up with me some time that week to say hi.

If you’re on your way to CAST 2013 in Madison in August, start out your conference with my Walking Skeletons, Butterflies, & Islands: an agile journey experience report.
I look forward to fielding your questions about agile testing!

Sadly, my talks will not be streamed online this year, but you might enjoy the webCAST lineup!

Tester Merit Badges live with 1 week to go for February!

22 Wednesday Feb 2012

Posted by claire in Approaches, Experiments, Exploratory Testing, Techwell, Tester Merit Badges, Training

≈ 1 Comment

With only a week left in February, I’ll be wrapping up my own trial of the first Tester Merit Badge and posting my results, so I encourage you to try it for yourself. Do let me know if you’re playing along at home!

For reference, here is the introduction and here is the motivation.

Originally posted on the Techwell blog, the badge description is reposted here for convenience:

Tester Merit Badge - Explorer

Tester Merit Badge: Explorer

Skill challenge: Try exploratory testing

Requirements

1. Know Your Maps.

Be able to explain different approaches to exploratory testing (e.g. testing tours, chartered session-based testing, freestyle)

Some web resources:
Session-based testing
Scenario testing
Exploratory testing in agile

Some books:
Crispin, Lisa; Gregory, Janet (2009). Agile Testing
Whittaker, James (2009). Exploratory Software Testing

2. North, South, East, West.

Who says scripted test cases can’t be exploratory? Just because you have a protocol written down doesn’t mean your brain turned off when you began to execute it. As you go along working through a set of instructions, perhaps drawing from a user manual if you lack test scripts or specific test cases, keep your eyes open for what is going on around you, not just what fits the happy path of the case. Make notes of testing ideas and chase down something that’s off-script and keep track of what you do as you go along. If no test scripts or highly structured test cases exist for a particular aspect you want to test, skip ahead to requirement #3.

3. How Long and How Far.

Using an existing reference (if any) estimate the time to exploratory test an aspect of a feature of a software product. If you have been using test cases or test scripts for this testing, then use those as jumping off points for your exploration but don’t follow them. I tend to make a list of some test ideas and then pick and choose which ones to attempt during a particular exploratory session. If no ready-made resources exist for a particular aspect you want to test, skip ahead to requirement #4.

4. Walk the Distance.

Estimate time exploratory test an aspect of a feature of a software product without the aid of any existing materials. Use your knowledge and experience to take an educated guess at what needs to be done and build up a guess-timate. We’re going for ballpark and not precision here. Then, try it and see how close you were. That’s the beauty of iterative learning.

5. Map Maker. Map of the Place. Make a Model.

I see these physical representations of travel as essentially the same when it comes to software testing. This one is about precisely describing what you observe, which makes it a perfect artifact of your exploratory session. This could be a site map, a pairing of requirements description snippets with implemented user interface components, or even a sketch of different paths through a block of code (if you’re doing some white box preparation for your exploratory testing). We want to show what we observed rather than what we expect, so you can explicitly record your expectations if that helps you to clear your mind for the road ahead.

6. Finding Your Way Without Map or Compass.

Freestyle! Do some testing without any more explicit structure than a time box. Give yourself 15 minutes to wander around in an application without stating a particular agenda. You might even try accessing a piece of software through a less favored access point (e.g. a traditional website viewed from a smart phone).

7. Trail Signs Traffic.

This is an opportunity to write a different kind of test guide for another tester to follow. If we stick to the trail metaphor, you want to provide indications of the way out of the woods but you don’t dictate how the hiker travels between the boles of the trees bearing the blaze (or if you’re a big nature nerd the piles of rocks and sticks with their encoded messages about the trail ahead). I think Whittaker’s landmark tour is particularly apt for this example, so I recommend picking a part of your app to extract some landmarks. Avoid step-by-step instructions about how to wander between these milestones! You want to recognize the variation in execution that naturally occurs, even in the presence of a test script. In this case, doing it differently is a strength since you collectively will cover more of the application over time, although you may not encounter exactly the same scenery along the way.

8. Bus and Train Maps.

Use a publicly available source to map out a test. If you have a user manual for the application under test, that would be a good source for producing an expected route through an application. Just like a driver stuck in traffic, you don’t need to adhere to the planned route, so feel free to follow any detours that seem like better alternatives if you are feeling blocked or just want to take a more scenic route. Lacking a user manual for this particular product, try a description of some similar or competing product. Again, we’re exploring here, so having an inexact guide is no barrier to the experiment.

When you complete any or all parts of these badge “requirements” take a moment to reflect on whether the technique could be helpful to you in your regular testing work. You don’t have to migrate away from your current approach, but having some options always helps me to switch it up a bit when testing starts to feel monotonous – and I really think I’m doing it wrong when testing bores me! There is always too much testing to complete, so I certainly need to go exploring more often.

Drop me a line or post a comment here to let me know how the experiment went for you and I’ll post my own results here within the month.

Happy testing!

Image source (embroidered version of this image)