A New Thread

(Mirrored from http://www.quardev.com/blog/2010-08-26-551545950)

Some of you know me and my brother James as exploratory testing practitioners.

You also know us as firmly aligned with the principles of the Context-Driven School. But sometimes we’re more known for being the guys who created Session-Based Test Management to solve the problem of how to manage and report effort from exploratory testing.

Ten years ago, SBTM was considered a pilot project with promise. Dreamt up on a napkin at a Denny’s in Boise, Idaho in March 2000, it was showing a lot of promise. We had done 150 sessions worth of experimentation by this day (August 26) of that year and liked where it was going.

I was struck by how powerful and efficient it was. For the first time I had a method for creating sheet music for jazz – a way to describe creative, improvisational work, and make it understandable and measurable. We didn’t invent exploratory testing, we had designed words and structures for it to give testers and managers a new way to describe their work to stakeholders other than to say they were “just playing around.”

Well, James and I have a new context-driven idea to experiment with. Like SBTM, it is meant to help you describe activities you’re already doing.

I picked James up in Seattle yesterday after he returned from a difficult project. A lot was going on in a small amount of time – a project with typical daily chaos. We went to my favorite sushi place and talked about it. He couldn’t disclose much because of NDA, so he talked in patterns and generalities, but he said something simple that stuck:

“Seemed like I did a lot of my work in threads.”

“Threads?” I asked.

He explained there are situations where we might leave a task and come back to it many times.

I agreed. That was a typical day for me at Quardev and as a tester on most projects I’ve worked.

He said that since the nature of the task could change over time, you wind up pursuing it like you pursue a thread in a conversation.

I agreed there, too.

“When our work is so tentative and exploratory,” he said, “the word ‘task’ seems too narrow a word to capture it. It’s really a thread.”

We talked about what it means to follow a thread, work in threads, drop a thread.

An artifact-based approach to test management usually aims to create documents like test cases. But the concept of working in threads de-emphasizes artifacts. It focuses on what you actually do: it’s an activity-based approach, not an artifact-based one. It’s meant to emphasize the learning that happens along the way toward solving an authentic problem.

James and I agreed that a session charter is an example of a thread. But where a charter seemed to differ from a thread is that a charter is a commitment, an agreement to accomplish a task (or set of tasks) in a session. A thread, on the other hand, has no such agreement or commitment, and no timebox as sessions do. It’s more general.

In short order, we had created a new sibling for SBTM, and we called it Thread-Based Test Management.

TTM is a generalized form of Session-Based Test Management.

While SBTM seeks to manage exploratory testing in timeboxes toward a commitment or agreement to execute a charter, TTM is more general – with threads focused on emerging problems and objectives that you need to solve.

You choose an activity that needs to get done, and you follow that thread. You follow it hither and yon, up and down, back and forth, round and round, over hill and dale until you decide it’s over – that further time spent on it is not worth it (for now).

Think of threads as the Notes you take in a session report. It’s the list of activities that tell the testing story of that session.

With threads, James and I are suggesting a new pattern of testing activity we think all knowledge workers already do, and we offer a way to think about managing activities you might do while on a thread.

The premise of TTM is this:

There are kinds of projects where we cope with a great many interruptions as we pursue objectives. How could we manage testing if we embraced those interruptions?

TTM is a test management approach that organizes testing around patterns of activity (“threads”). By identifying and organizing threads we’d might be able to keep testing on track and provide a credible report of the ongoing story of the test project.

James and I left the sushi place after flushing this out a bit more and continued our “Thread Theory” discussion back at Quardev. We set up shop in a conference room where we were quickly interrupted by Quardev’s Enterprise Manager who needed status from me on a project proposal. I excused myself from the room and let James hash some stuff out on the whiteboard about what TTM could be, knowing I’d return soon.

15 minutes later, I returned, picking up that thread with him – the one about exploring what Thread Theory could mean. We resumed a brainstorm about the mechanics and philosophy of why it could have value to label the interruptible courses of action we take when we test.

We discussed what might happen in the course of a day of following threads.

You could:

– focus on one thread or many;

– drop threads;

– create new threads;

– pick up dropped threads;

– “comb” threads by creating a structure to organize them;

– “knot” threads by declaring a meaningful checkpoint in your exploration;

– “untangle” threads by uncovering new context or seeing a pattern that’s valuable to know;

– spawn child threads;

– realize an overarching parent thread…

Fifteen minutes into these bullet points on the whiteboard, the conference room phone rang again. It was Scott, apologizing for the interruption but wanting clarity about insurance for a subcontractor as part of the proposal we were working on earlier.

Ah, the “Scott/proposal” thread I dropped earlier had resumed.

We let it interrupt us because it was important (and a self-referential example of embracing emerging context on another thread), and after a few minutes, James and I resumed (again) our other thread of talking about Thread Theory on the whiteboard.

Another 15 minutes later, Scott came into the conference room, reporting that the idea we had given him earlier about the subcontractor insurance had some merit in a call he had just made in the other room.

When you’re following threads, it doesn’t matter how many times they get interrupted, it’s about being aware that the number and types of threads you’re following might help you tell the story about your day of testing and solving problems.

Some people report their day around the stories they develop or test.

Some people report sessions.

Some people report the test cases they ran.

James and I suggest a thread paradigm because it may be more useful on chaotic projects to get to the heart of what we actually do – follow the flow of thinking and activities around solving ambiguous problems.

So, yes, he and I had just two threads going on for a few hours yesterday. If we were taking notes about our day or making a report to some stakeholder that mattered, these two threads would be included in what we learned or what value we created. If there were an Agile-style standup the next day, I may decide to talk not in stories or session charters, but in threads-followed.

Whenever you think, “I need to get something done” or “I need to solve a problem”, TTM is a way to manage that.

Since it’s about maximizing opportunities and following the flow of problems, there are two main questions that are useful to ask:

1) Primary: “What thread is most important right now?”

2) Secondary: “On what thread can we make the most progress right now?”

Whether or not you call them threads, these patterns of activity are already there in our day. Knowledge workers (like testers) already know this.

When we find a bug and start our investigation into how bad it is, that’s a thread.

When the Triage Team has a question and we test because we think we can give them more more context to make a better decision, that’s a thread.

When we need to know if testing in the cloud is a solution for us, and start researching VMs, Hyper-V, Azure, and different notions of virtualization, that’s a thread.

And instead of lamenting the interruptions to those missions, we hope you take them in stride, asking the two questions above. Maybe it makes sense to cut your current thread for now because of something more urgent. Maybe make a knot or two along the way, comb through some tangles, discover a child thread lurking, or drop a thread entirely and pick it up later. Maybe devote a thread to tie up loose threads. That’s the spirit of TTM.

Either way, try it. When someone asks you how you day went, talk in terms of threads-followed or threads-in-progress, not artifacts-produced.

As you’re reading this, James has written a simultaneous blog on this topic that goes into more detail.

2 Responses to “A New Thread”

  1. Bill Matthews Says:

    I really like the metaphor of using threads and the way you and James describe makes it seem very natural and logical.

    It seems to me, that SBTM focuses on managing test execution whereas TTM (TBTM?) is more about managing the tasks around testing in the wider context. Is that correct or do you normally use sessions for tasks such as creating the test strategy, research, writing reports etc.?

    Not sure it is specifically for Test Management as there is nothing specific to testing about the approach you put forward; sure the approach can be used to manage testing but the same approach can be used in other contexts….it’s about Life Management!

    As mentioned in both posts, it is something that many are probably already doing, possibly without realising it but by identifying it, naming it and analysing it you make other aware of it and so better able to work with it – it’s one of the things I really like about you and James.

    I’ve used a similar approach to Threads for a while and it’s based on (and slightly corrupted) the idea of the BurnDown chart from Scrum as a way to manage streams of testing work; sometimes this is within the context of Agile projects sometimes not (e.g. a PRINCE2 driven project). It tends to be local to the test team and used to track our activities and report into the higher level project tasks.

    Many project management methods are product/artefact driven (i.e. each task delivers a product of some description) which hides the complexity of the activities needed to complete the task. So I tend to use the BurnDown chart to identify and track these activities. The chart is used in a similar manner to your Threads in as much as the list is dynamic: items get completed, parked, deferred or removed, new items get added, existing items spawn other items etc. I use it to track progress and effort and to get a handle on how much work we think we have on at any given time. When the testers meet to discuss progress we are talking about what’s on the list, what we’ve completed, how long we currently think we have left to complete an item, what’s stopping us finishing an item, new items that need to be added and so on. Often items are ordered around project level tasks so that I can more accurately report to the project manager how we are progressing against their tasks. From the current set of items and estimates we can see how we are progress against target milestones and take action if needed or understand why we missed a milestone (e.g. we’ve identified some new items that needed to be completed).

    Where my use of the Burndown chart differs from the traditional use is that a person may be allocated a number of items from the list rather than only having one task at a time. Scrum would also suggest that you pick the highest priority unassigned item to work on. My approach is generally based on what is the best use of our time and resources at a given point, which may be the highest priority item but may just be an item that we just want to get out of the way (i.e. make the most progress on).

    Perhaps I’ll stop calling a Burndown chart and instead call it a Thread chart or something.

    Regard
    Bill

  2. Test Size Matters: THINK BIG, test small! | QA Intelligence - a QABlog Says:

    […] about Exploratory Thread-based testing by the Bach Brothers – here are both by James & Jon) you actually motivate your testers to THINK BIG and take more responsibility for the test […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: