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

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.

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.

I heard that Gerry Weinberg has an exercise called “Mary hada 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.

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.

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

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

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)?

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.

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!

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.