I’ve been working with exploratory and session based testing for a while now and I like this form of testing for its flexibility and adaptability. I manage my sessions with session based test management, outlined by Jonathan Bach in his “Session-Based Test Management” paper  with a small addition; I also record all of my session with a screen capture tool. With sessions spanning up to 90 minutes, the screen captures becomes rather large files, even with compression. It also takes a fair bit of resources from the computer to capture and encode in real time, so why do I insist on doing this for every session?
First of all, I’m mainly testing web based software, where I do not have to be overly concerned about what consequences to the SUT the extra load on my PC might have. If I tested locally installed software, I would have to take this more into consideration, but I’ll cross that bridge when I get to it.
The advantages that I see in capturing each and every session are:
- Attaching snippets to bug reports
- Reviewing captures to help reproduce bugs found in sessions
- Helping me keep focused during the session
- Allowing me to be the navigator
Attaching snippets to bug reports
From the capture, I can cut out snippets that highlight a certain sequence or error that I have experienced during the session. This might be the most obvious of the advantages, but I rarely use it myself. The reason for this is that I will generally try to reproduce the bug in a simpler and more straight-forward manner than how I first saw it in the session. When I succeed in this, then I keep to reporting the steps I’ve taken, possibly with attached screenshots. It’s only when I can’t reproduce the bug that I cut out the snippet from the video and attach to the bug. In this case, the snippet is very valuable, though.
Reviewing captures to help reproduce bugs found in sessions
This part ties into what I wrote in the previous section. Personally I like to stay with the charter as much as possible in a session and avoid things that break my “flow”. One of the things that I have found breaks my flow is reproducing and reporting bugs. In a session, when I find something that looks like a bug, I like to just make a note of it in order to return to it after the session. This is just a personal preference and others might prefer to investigate bug when they are fresh in memory, but if you work like me and just make a note of it, it’s crucial to remember what you did to provoke the bug. In most cases I can remember it from the notes I make, but in a few cases I only think I remember, but I have actually missed a small, but critical step. In these situations, I can go back and review the video to retrace my own steps. Just finding that missing step makes the whole recording worth the effort.
Helping me keep focused during the session
The two first advantages have been reasonably objective in what they can help with. The two last ones are much more subjective and directly related to the way I approach sessions. This one is purely psychological and based on the fact that I am very good at tricking myself. As everyone else, I want my sessions to be uninterrupted by email, IM, phone calls, etc. Unfortunately, I’m really bad at remembering to turn off IM, email notifications, etc., which means that I occasionally get notifications popping up on my screen during a session. With these notifications comes an almost irresistible urge to check the message behind the notification, but when I have the recording software running, it’s almost like having someone watching over my shoulder and I get a very bad consciousness if I actually check my email. I know that I can just pause the video, or cut out any part from it later, but that doesn’t matter; the video still helps me focus on the session.
Allowing me to be the navigator
This is an analogy to the roles in an XP team and ties into how I like to work with sessions. In an XP pair, there is a “driver” that writes the code and focuses on details and a “navigator” that looks at the bigger picture, design, architecture, etc. In a session, I like to be the “navigator” in the sense that I don’t want to get bogged down in details about a bug; I want to follow the flow of the charter, think of new tests and notice irregularities in the software. Since the video will record every step I take, I don’t have to divert attentions to this, but can focus on what I want to do in the session.
Those are the advantages I see in recording every session I perform. You might ask how long I store these files, considering the size of each file. As with most other things, the answer is that it depends. I’m likely to keep all recordings for one iteration, if that’s how the development is done, but if some bugs are left open after an iteration, I might consider keeping the video until the bug is closed, just in case the developers need some extra information that I did not think of when reporting the bug. If I have a large enough hard drive, I can even consider keeping all of the videos until the end of the project/release.
In my day-to-day work I use Ubuntu Linux and I always try to use this for testing, whenever the requirements do not prevent this. I like Linux for several reasons, one of them being the abundance of free utilities, for example the ones I can use to record and edit videos. To record my session on Linux, I use XVidCap  and for editing the videos and extracting snippets I use AVIDemux . I know that there are several good tools to both Windows and Mac (albeit not for free), but I do not have any personal experience from using these.