I often test alone. But then testing is a rather solitary activity much of the time. So is writing. Not surprising, introverts have a way of finding activities that leave them alone.
When I teach, I talk about using debriefs. I’m frequently surprised at how few people use debriefs.
If you’re unfamiliar with the term debrief , then I’d suggest begin by looking at the basic definition. I like returning to definitions, I find wrapping my head around a core term and definition is a more comfortable way to start learning something. Then expand on from there. James Bach has a great checklist for debriefs, here.
I don’t personally look at debriefs like an interrogation, a word you’ll see come up when you look at its basic definition. Instead, I prefer a more gentle approach. I think of a debrief as a time to be reflective. And I like having lots of time to reflect, I seem to need it.
So people ask me how I debrief if I’m testing alone. After all, debriefing is a joint activity. A conversation with someone else gently (or perhaps not so gently) prodding you with questions can help us realize new things or pay attention to things we may have missed during a testing session.
But you have to work with what you have – not what books or other people espouse about what you’re supposed to do. You have to find your own way. Since I work alone frequently, I’ve had to learn how to talk to myself. I’ve adapted. And yes, I do answer my own questions.
Some things I do have become such built in activities that it’s almost hard to distinguish them and write about them, stuff just is.
Debriefing is one of those activities.
So I’ve spent some time reflecting on what I ask myself, how do I reflect on my testing sessions – what questions do I ask myself to help me reflect, regroup and then go on.
In the quiet of my own mind without having to worry about the ramifications of time estimates altering the project or any other impact my answers might have, I ask myself these questions. And I often ask myself lots of why questions to my own answers because I’ve learned that underneath the why questions – a lot of good information can hide.
- Have I skipped anything?
I find that on occasion a new feature will have some complication that I haven’t understood yet and when I’m slow to approach something, it means I have a block somewhere that I need to overcome. So I ask myself, have I skipped past something? Why?
- Do I have any hunches?
Often where I suspect there are issues, there are. Sometimes I haven’t found what the issue is or what works “clunky” but my early hunches usually result in bugs. These hunches are hard for me to share with anyone because I might not yet be able to quantify, replicate or prove it. This is where I like my solo debrief sessions, I don’t have to worry about ramifications of my gut thoughts. My thoughts are inklings for me to explore at this point.
- Did I observe anything that made me hesitate?
Along the path to testing something, issues pop up. Sometimes I’ll push past a smaller issue to move on, to get to some other state, condition or idea I have. Now might be the time to go back and make sure I’ve tracked down anything that I’ve hesitated over. Did I miss noting down any of those hunches? This is a good time to take the time to write up more notes. I remind myself that my notes can be private so I don’t have to worry about having “silly” ideas.
- Where do I feel I need to spend more time?
I like asking myself this question because I use it to force myself to be brief and list. List making can be telling. It often reveals an area I haven’t tested in awhile or an area that I have some hunch. This is another tactic, another question that I prod myself with. And then – I ask myself why?
Why do I feel I need to spend more time?
- Do I have doubts about the functionality working? Have I seen something to make me feel this way? Or have I not seen enough in an area to give me comfort that is working?
- Regression. Is this an area that needs some regression testing? Why – what specifically? I realize sometimes by asking myself this – I can specifically identify what I need to regression test.
- Need more confirmation. Sometimes I’ll test something and it will work fine. I’ll test and not find an issue and yet for some reason, I haven’t developed a sense that everything is ok. This is a hunch of some sort. There is some permutation or data or something I haven’t seen or tried yet. What, what is it? I prod myself along to see if I can distinctly figure out what feels undone.
- If the product were to ship now, what would make me uncomfortable?
I like this question a lot. Not what haven’t I tested, not what work remains – instead this is another way for me to find out my gut feel about what isn’t ready yet either because testing has been light or I don’t have enough belief assurance that something is working.
- What feels done?
After thinking about what feels undone, it is a source of comfort to me – to help me from feeling overwhelmed about what remains to become clear about what does feel done. And it is telling when something doesn’t end up on this list and yet it didn’t show up on my list of what was skipped or what hunches I have.
I trust my instincts so I don’t dismiss anything I find when I reflect this way. And I believe that over time, this is a way we can learn to trust our gut, to develop our instincts. I tend to be a pretty reflective person. I need space around activities to think.
With so much information coming at us during the day, when and how can we find our way through information that get shared with us as well as information we gain from our test sessions to know where to go next? Testing well done, is strategic. Strategic thinking requires that we reflect on information gained to plan next steps. So perhaps ask yourself, if you don’t use debriefs, when do you reflect, regroup and potentially redirect or reconfirm what your next testing activities will be – whether for yourself or for someone on your team?
