• About
  • Giving Back

aclairefication

~ using my evil powers for good

Category Archives: Exploratory Testing

Agile Testing Days USA links

27 Wednesday Jun 2018

Posted by claire in Agile, Agile Testing Days USA, Approaches, Coaching, Context, Experiences, Experiments, Exploratory Testing, Podcast, Publications, Soft Skills, Speaking, Training

≈ Leave a Comment

Refactoring Test Collaboration from Claire Moss

Here are some resources we’re using in my Agile Testing Days USA workshop Refactoring Test Collaboration

Slides

Abstract

Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.

As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:

  • Where do testers get their ideas?
  • How are you planning to accomplish this proposed testing, tester?
  • Why not automate all the things?
  • Who is going to do this manual testing and how does it work?
  • How do we know whether we’re testing the right things?

Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.

Key-Learning

  • Approaches to handle objections to executing the testing work
  • Ways to mentor test helpers, including pairing
  • Investing in testing the team believes in
  • Understand how other team members have been testing the work so far
  • Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable

Resources

Refactoring

Collaboration + failing at collaboration

WHOSE testing skills + Exploratory testing + Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF] + book Explore It!

Agile Manifesto

Walking Skeletons, Butterflies, & Islands + my blog post elaborating on the conference

Big Visible Testing + my blog post elaborating on the presentation

Testing pyramid + critique of the testing pyramid/alternatives

Extreme programming lifecycle

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps + Role mapping

Westrum model + organizational culture & safety

Linda Rising’s change patterns & books on Fearless Change

Deployment pipeline

High Performance Practices [PDF] + book Accelerate

Continuous Testing

Empathy-Driven Development + empathy practices

Many interactive aspects of my workshop were inspired by Sharon Bowman’s book Training From the Back of the Room

facilitation book Collaboration Explained

metrics book Measuring and managing performance in organizations

book Testing Extreme Programming + some follow-up thoughts

Soon to come! Claire Moss on Let’s Talk About Tests, Baby podcast

deliver:Agile2018 Links

02 Wednesday May 2018

Posted by claire in Agile, Coaching, DeliverAgile2018, Design, Experiences, Experiments, Exploratory Testing, Publications, Speaking, Training

≈ Leave a Comment

Beyond Waste: Exploratory Charters in Action from Claire Moss

Here are the links we’re using in my deliver:Agile2018 workshop Beyond Waste: Exploratory Testing Charters in Action

Slides

Abstract:
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

Learning Outcomes:

  • Structuring manual exploratory testing for transparency
  • Charter guidance during test execution
  • Outcomes of exploratory testing
  • Value delivery through debrief of testing session

Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF]

Which world do you prefer?

UI: https://xkpasswd.net/

UI: http://correcthorsebatterystaple.net

UI: http://password.optionfactory.net/

NodeJS: https://github.com/fardog/node-xkcd-password

Ruby: https://github.com/rasmus-storjohann/xkcdpass

Python: https://github.com/redacted/XKCD-password-generator

Shell: https://github.com/danielmcgraw/xkcdpass

PHP: https://github.com/cesarzavala/xkcd

Perl: https://github.com/CS-CLUB/xkcd-936

Guest Author in Better Software

15 Wednesday Jan 2014

Posted by claire in Approaches, Better Software, Experiences, Exploratory Testing, Publications, Visualization

≈ 1 Comment

Check out my recent article Feeling Lost in the Woods? Mind maps Can Help! [PDF] on page 26 of Better Software magazine.

LostInWoods

Claire takes us on a nontraditional journey where designing and implementing testing approaches can be rapidly organized into a hierarchy of connected elements. Mind maps, used primarily for visual and conceptual thinking, may be just the answer for quality assurance professionals.

Est testing parfait?

19 Tuesday Nov 2013

Posted by claire in #testchat, Agile2013, AgileConnection, Experiments, Exploratory Testing, Hackathon, ISST, Lean Coffee, Podcast, Retrospective, Skype Test Chat, Social media, Software Testing Club Atlanta, Speaking, Tea-time With Testers, Techwell, Test Retreat, Testing Circus, TWiST, Volunteering, Weekend Testing

≈ Leave a Comment

I heard that Gerry Weinberg has an exercise called “Mary had a little lamb,” in which you analyze each word in the sentence to elicit implicit meaning that might be important. This sounded interesting enough to try, so when the opportunity came to propose a topic at Test Retreat 2013 I went for it. My topic “Is testing for me?” didn’t end up formally scheduled but made a nice interstitial topic to discuss with those milling about in the main room.

I chopped the sentence into separate words and wrote them top-to-bottom on a large sticky note. Then, instead of giving some sort of prepared remarks, I elicited brainstorming from the gathered participants. Having received interesting feedback on my professional and personal strengths at Agile2013 that had left me questioning how best to use my evil powers for good, I wanted to hear how others were thinking about the testing field and how it fit them.

The resulting scrawled notes ended up a mindmap, the path of least resistance for me. I won’t say the discussion solved all my problems, but it did give me some direction for future exploration – exploration that might also be helpful to a newbie wondering whether to pursue a career in testing.

Is testing for me?Which brings me to some interesting recent events:

  • the first ISST webinar by Ben Kelly
  • Our second meetup for Software Testing Club Atlanta
  • Randomly running across a new tester on Twitter
  • This testing blog post I read recently

I started composing a list of things I’d recommend to people just starting out as testers to help them to evaluate whether to continue. I wanted to encourage them to jump right in but also think big, not waiting them to wait 5 years to reach out to the wider world of testing (like I did).

Here’s my current list. I blogged about various experiments I tried, so you can read for yourself to see what it’s like to select what’s a good starting point for you.

  • First things first: Whatever you try, frequent retros
  • Social media, especially Twitter
  • Try exploratory testing
  • Weekend Testing
  • Chatting with other testers online
  • Books, Podcasts, Blogs, maybe even writing for some ezines or websites?
  • Meetups, local events, Lean Coffee, conferences – attend (in person or virtually), live-tweet a conference, volunteer, speak (lightning talk, whole session, workshop, tutorial)
  • Open Source, Hackathons, innovation days, etc
  • uTest/Applause? I’ve heard of this but not tried it. Seems like a lower barrier to entry/way to get started?
  • And, last but not least, who do you want to be?

No matter how many times I think I’ve found all the meaning in my testing career, suddenly I realize there are more layers… but like a parfait, not an onion.

Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. What about cake? Everybody loves cake!
Shrek: I don’t care what everyone else likes! Ogres are not like cakes.
Donkey: You know what ELSE everybody likes? Parfaits! Have you ever met a person, you say, “Let’s get some parfait,” they say, “Hell no, I don’t like no parfait”? Parfaits are delicious!
Shrek: NO! You dense, irritating, miniature beast of burden! Ogres are like onions! End of story! Bye-bye! See ya later.
Donkey: Parfait’s gotta be the most delicious thing on the whole damn planet! – Shrek

Thanks for the inspiration to write, EmJayKay80 and Niyi!

Tea Time

05 Saturday Oct 2013

Posted by claire in Experiences, Exploratory Testing, Tea-time With Testers

≈ 3 Comments

TeaCollectionA little history

So as you may have gathered, I’m an American. But not just any American. I’m from The South. In fact, I’m a very special kind of Southerner: the mythical Atlanta native. (Though some would argue that prevents me from being really Southern.) While most of you are likely to pass through our airport, I was born and raised here. That has resulted in a certain expectation when you mention the word tea (i.e. it should be used in the phrase “sweet tea”). Now Southern sweet tea isn’t “one lump or two” but more the kind of thing that induces diabetes. You don’t make it by the delicate little tea pot, you make it by the gallon and it’s always caffeinated. If you’re feeling really fancy, then you make sun tea. Carefully. Or you mix in a bit of lemonade and voilà, Arnold Palmer. The important thing to remember here is to serve it sweet – and cold.

Wait, what?

So you can imagine my curiosity when I discovered that most of the world drinks tea hot and brews it from “loose leaf” not tea bags. What’s that about? I had to find out! When I mentioned it to a friend, she showed up at my house bearing a beautiful enameled tea pot as a gift. It was time to learn a few things. I made a foray to a local tea shop and discovered that not only were there non-black tea options out there, but not everyone drinks it sweet. (Okay, so I might be livening things up here a bit, but it was still rather revelatory that this was a complex process.)

An app for that

I found out that the retail chain Teavana has an app. I decided I could use some help with brewing tea when my friends were not available to tell me what to do, so I downloaded it onto my smartphone. While the app clearly has a revenue purpose, driving you to purchase their detailed catalog of products, directing you to their online shop or to a local store, and showing recommendations for blending teas, it also has a tea timer. So I tapped on the brewing icon and stopped to investigate.

The first thing I noticed was the list of tea types that defaults to having Oolong selected. I don’t even know what oolong tea is, so I tried tapping the icon for additional information to no effect. I thought about referencing their catalog of Teas with its detailed descriptions of tea varieties in order to understand it better, but I didn’t see that option in the buttons at the bottom of the app. Accepting this usability problem in favor of actually making some tea right now, I went for the old standby and selected Black Tea. The generic black tea brewing instructions included measuring a volume of tea, but since I typically brew more than a cup at a time I had to do the math. No way to set up a preference for a full pot of tea here. The usability could use some love.

Some science

Then some perplexing data: 195 degrees. While I’m American and appreciate this default to the Fahrenheit temperature scale, I don’t have a kitchen thermometer, only human thermometers to use in case of illness. I was pretty sure that wouldn’t be suited to the purpose. (And it turns out there are thermometer testers! Don’t forget to calibrate!) Now I found myself heading to the internet for more data about water temperature. I’ll admit that I don’t know the temperature of boiling water in degrees Fahrenheit off the top of my head. And the first search result wikipedia article about boiling point, while interesting enough to open in another browser tab, weren’t helping me out here when what I wanted was a simple conversion. Okay, got it. 212 F is boiling and so too high for my black tea. Obviously I’d been doing it wrong my whole life. In the past, I’d just microwaved the water or boiled it on the stove, but now I should care about accuracy. Well that’s why I’m using the app in the first place, to gain some nuance in my tea preparation. The first step is admitting you have a problem.

Let’s do this!

So I get the water hot but not quite boiling and take it off the stove burner with my tea ball filled and ready to steep. Pressing the helpfully labeled Ready to Steep button takes me to an adorable screen that looks like the tea steeper they sell for a single cup brewing. I’m happy to go with it because pressing the Start Steeping button plays lovely music as it counts down and that music varies with the variety of tea. The animation of the water level adjusting with the tilt of the phone with bubbles rising up and tea drifting down is so cute – until my smartphone’s screen goes to sleep. The music cuts right off. I go to wake the phone up only to see the prompt to begin steeping again… What? I glance at the clock, wondering how long I’d played with rocking the phone back and forth. What time did I start brewing? Argh! For a tea novice, this flaw is fatal. My tea comes out just as satisfactory as usual, but I’ve had enough hassle with the app that it’s not a useful tool.

Clearly time to turn off the phone, sit back with my “cuppa,” and find some creative inspiration.

[Note: Although this post is not related to Tea-time with Testers, you should definitely go read that testing ezine too!]

Always On

12 Thursday Sep 2013

Posted by claire in Approaches, Context, Experiences, Experiments, Exploratory Testing

≈ 2 Comments

FountainOfRings

So there we were, Josh Gibbs and I, enjoying our lunch break on a lovely sunny day at Centennial Olympic Park. As an Atlanta native, I was living here when the olympics came through town and have a brick in the park. We took a little stroll to visit it and then settled down by the fountain to enjoy the Fountain of Rings show that happened to be scheduled at that time.

As we sat there absorbing the novel touristy experience, trying to identify the musical strains that blared from the speakers, we started to analyze it. We couldn’t help ourselves. That instinct to see beyond the surface, to reverse engineer the system through a verbal exchange, was too powerful for us to just be in the moment. This is why we can’t have nice things.

However, as we gazed upon these new and shifting patterns of water jets set to music, we noticed a flaw in the system. One water jet was misbehaving. At first, it seemed like some sort of counterpoint to the carefully orchestrated flow, perhaps a harmony in the song that I couldn’t properly detect. As the songs changed and that jet continued to spray, it became clear that it was out of turn.

So we started looking for rules we could test to explain the behavior systematically. We speculated that the jet was always on, but when the song ended the water completely died away. We proposed that this little jet was always spraying water, always turned on but only as long as any water was emerging from the fountain. When some jets were performing but the jets around it were not active, this jet bubbled closer to the ground, but as the jets around it reached for the sky the broken jet struggled and failed to follow suit. So that rule seemed to hold.

We considered the historical context of this fountain. Constructed for the 1996 olympics, the initial design had to be created with technology available at that time. So what kind of controls were determining where the water flowed, how long the water flowed (to produce the varying effects from a water ball to a towering jet), how hard the pressure was (to provide a jet of a particular height), how quickly the pattern could change, and so on? Had the original system been maintained all this time? How would you upgrade a system like that? Was there a fixed playlist with predetermined songs and water choreography or could someone provide new inputs? If you could submit a new sequence, was it possible to hack the fountain? And if so, what was the risk involved (likelihood, impact)?

(This just in: The playlist changes and, yes, the computerized fountain accepts new inputs! “The computerized Fountain can be programmed with special announcements as well as a variety of water displays including low-pressure, walk-through “water curtains”, fog and misting.” )

I think we left with more questions than we answered, but it was still a fruitful conversation. It was a nice little trip down memory lane and forced me to confront the reality that testing is a way of life, a path that I am always on.

Live testing – End-to-End Agile Tutorial – CAST 2013

26 Monday Aug 2013

Posted by claire in CAST 2013, Context, Experiments, Exploratory Testing

≈ Leave a Comment

Shelfari: Book reviews on your book blog

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.
Agile2013_Speaker_banner

 

 

 

 

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!
CAST2013_LessonsLearned

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

E v A

05 Friday Oct 2012

Posted by claire in Automation, Exploratory Testing, Podcast, Publications, TestCoachCamp 2012, TWiST

≈ Leave a Comment

EvA

Back during Test Coach Camp 2012, Michael Larsen made some great recordings of our open space sessions. Subsequently, he published Ken Pier‘s session topic E vs A – Huh? under the title Exploratory vs. Automation in the TWiST podcast feed.

I had fun explaining our testing team’s approach to exploratory testing and automation while learning from some helpful members of the testing community, including Cem Kaner, Doug Hoffman, Matt Barcomb, Phil McNeely, and Michael Larsen.

Check it out!

You can stream these podcasts online or download after registering for the Software Test Professionals’ website, and membership is free.

Here are the direct links (once you log in):

Exploratory vs. Automation, Part 1
Exploratory vs. Automation, Part 2

Image source
(P.S. I can’t resist reading this article that pointed me to the image: The Semiotics of Hello Dolly!)

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)

← Older posts

♣ Subscribe

  • Entries (RSS)
  • Comments (RSS)

♣ Archives

  • October 2019
  • September 2019
  • August 2019
  • March 2019
  • February 2019
  • November 2018
  • August 2018
  • June 2018
  • May 2018
  • March 2017
  • August 2016
  • May 2016
  • March 2015
  • February 2015
  • February 2014
  • January 2014
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • May 2013
  • April 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • August 2012
  • July 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011

♣ Categories

  • #testchat
  • Acceptance Criteria
  • Agile
  • Agile Testing Days USA
  • Agile2013
  • Agile2018
  • AgileConnection
  • Approaches
  • Automation
  • Better Software
  • CAST 2011
  • CAST 2012
  • CAST 2013
  • CAST2016
  • Certification
  • Change Agent
  • Coaching
  • Context
  • DeliverAgile2018
  • Design
  • Developer Experience
  • DevNexus2019
  • DevOps
  • Events
  • Experiences
  • Experiments
  • Exploratory Testing
  • Hackathon
  • ISST
  • ISTQB
  • Lean Coffee
  • Metrics
  • Mob Programming
  • Personas
  • Podcast
  • Protip
  • Publications
  • Retrospective
  • Scrum
  • Skype Test Chat
  • Social media
  • Soft Skills
  • Software Testing Club Atlanta
  • Speaking
  • SpringOne2019
  • STAREast 2011
  • STAREast 2012
  • STARWest 2011
  • STARWest 2013
  • Tea-time With Testers
  • Techwell
  • Test Retreat
  • TestCoachCamp 2012
  • Tester Merit Badges
  • Testing Circus
  • Testing Games
  • Testing Humor
  • Training
  • TWiST
  • Uncategorized
  • Unconference
  • User Experience
  • User Stories
  • Visualization
  • Volunteering
  • Weekend Testing

♣ Meta

  • Log in

Proudly powered by WordPress Theme: Chateau by Ignacio Ricci.