Describing, Not Prescribing – Vol 4: Refining The Expeditionary Technique

In my previous posts on the topic, I discussed a move away from “prescriptive” test cases towards a more descriptive technique using mindmaps. We’ve been exploring this technique for a couple of months now, and have made a couple of refinements.

I think the best way to discuss them is with a hypothetical example.

An Evil Example

Let’s say we are testing an innovative new mobile app for supervillains. The app is meant to help manage a supervillain’s fortress. It can monitor camera feeds, order reallocation of henchmen from one part of the fortress to another, ready the escape vehicle, and trigger the fortress’s self-destruct doomsday device.

I made a mindmup to discuss my initial testing ideas for the app, based on its high level descriptions:
MFM_NotStarted

Collapsing Nodes

Note that this seems like the testing activities are described at a very high level. Somebody looking at this knows the kinds of activities I’m planning on, but this is a bit light in terms of detail. That’s because I’m using Mindmup’s Expand/Collapse feature to hide the complexity of the test ideas. Note that a lot of the nodes look like a stack of cards. That means they are a collapsed node. Nodes can be expanded or collapsed by via the context menu or by hitting Shift-UpArrow:
MFM_ExpandNode

So, there’s actually quite a bit in this ‘mup. It’s just that a lot of the test ideas are inside these collapsed nodes. This can be helpful to reduce the cognitive overload that happens when you open map with a lot of stuff in it.

The Platform Problem

This was one of the trickier bits that we encountered and had to solve while working with the ‘mups. I’m using the SFDIPOT mnemonic to get my initial blast of ideas into the Mindmup… I’ve found that to be a really useful technique and I intend to keep using it, BUT there’s a gotcha built into the system if you do.

The problem is with the Platform node. My Platform node, expanded, looks like this:
MFM_expandedPlatformNode

I put into the Platform node all of the devices I could think of that I might want to test with. Seems like a useful exercise: We want to enumerate those things and make sure we are thinking about device coverage. So what’s the problem?

Let’s look at the monitoring functionality again:
MFM_MonitorNodeExpanded

Say I want to spend some time testing the submarine bay monitoring with an iPhone 5. Do I put that test under “submarine bay”, or under “iPhone 5”?

Here’s what we came up with (apologies for the 1 minute gif, but it… might be worth it?):
MFM_ReportingResults

The Platform node is just a list of platforms we’re interested in. We don’t put test ideas in there and we don’t mark down test results in there. Instead, when we start to test an idea, we open up a new node that describes the platform. Then we go into the Node Attachment (hotkey: A), mark down our initials and the date, and then report the results of the test. If we find bugs, we make child nodes of the test that represent the failed part of the test. That way, when it is fixed, it will be easy to see what we were doing when we found it. We can then retest it and mark it “Passed,” which in Mindmup will also mark its parent as Passed.

(Note that I also added a new node after I did the camera test in the submarine bay, because when I tested it I found out about functionality I didn’t know about. This is very common.)

In this way, we can gradually build up a testing picture. We can see what was tested, by whom, on what platform, and we can see what happened. We can also see tests that could (should?) happen in the future but haven’t yet.

How’s it going?

Now that we’ve worked out the platform problem, this feels pretty good. I particularly love how it feels to go back and see the original test results in the attachments when I am testing bugfixes. There’s a lot of rich context around it, and I feel like I’m writing the history of the product as I add more notes to the attachments over time.

In a couple of weeks, I’m going to be doing a full-on regression test of my (very complicated, enterprise-level) product using this technique. Wish us luck!

As always, share your questions and experiences in the comments!

Advertisements

One thought on “Describing, Not Prescribing – Vol 4: Refining The Expeditionary Technique

  1. Pingback: Testing Bits – 12/15/13 – 12/21/13 | Testing Curator Blog

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