Soap Opera Testing. [from Exploration

Soap Opera Testing. [from Exploration Through Example]

Here’s something I wrote for the member’s
newsletter of the
Agile Alliance.

To me, testing is about more than finding bugs. It’s also about
helping the whole team understand the domain and the needs of the
users. It should be a way of provoking insight.

One good technique is from Hans Buwalda
(www.happytester.com). He
calls it “soap opera testing”. It goes beyond the straightforward
scenarios that teams often use in development. Soap opera tests
exaggerate and complicate scenarios in the way that television soap
operas exaggerate and complicate real life. Here’s an example:

“A customer named Marick hires a car for a three-day business
trip. (This, by the way, gives him enough rental points to reach
Preferred status.) Midway through the rental, he extends it for
another week. Several days later, he calls to report the car has been
stolen. He insists that the Preferred benefit of on-site replacement
applies, even though he was not Preferred at the start of the
rental. A new car is delivered to him. Two days after that, he calls
to report that the “stolen” car has been found. It turns out he’d
mis-remembered where he’d parked it. He wants one of the cars picked
up and the appropriate transaction closed. Oh, and one other thing:
the way he discovered the mislaid car was by backing into it with its
replacement, so they’re both damaged…”

Soap opera testing is a kind of brainstorming, one that surfaces
questions easily overlooked. When does Preferred status kick in? What
are the implications of renting two cars at once? Like other types of
brainstorming, it’s best done in a group.

When I sent that text to Hans, he had some interesting comments that
need to be written down somewhere public. So the above is by way of
introduction, and here’s what Hans had to say:

There is more to say, but these two points would be the most
important:

  1. Involve (in the group) some “real people” to get ideas, like experienced
    end-users, subject matter specialists, but also experienced testers (the old
    fashioned craftman types) and of course developers (they know the
    complexities and weak spots).

  2. Cover/augment the scenarios with a list of “test objectives”, atomic
    statements describing what should minimally be tested, and match the
    objectives with the soap operas after(!) those have been produced. That way
    a potential draw back of soap opera’s (lack of systematic coverage) is
    effectively addressed.

Comments are closed.