(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.
Tested 