Mon, 04 Aug 2003
Soap Opera Testing
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:
-
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).
-
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.
P.S.: Ken Schwaber (the newsletter editor) was kind enough to let me
publish my blurb here even though the newsletter isn't out yet.
Join the Agile
Alliance and you can read it again! I quote Hans's email with permission.
## Posted at 14:21 in category /testing
[permalink]
[top]
More on change detectors
Jonathan Kohl writes:
After reading the
quote of Christian Sepulveda's point
on "change detection" on your blog, I tried it out in a
meeting today. It seemed to go over quite well with
people. I was talking about automated unit tests in
particular as "early change detection" as well as other
automated tests with regards to a goal of automation. I
asked what the goal of test automation was for the
company, and no-one had really thought of it.
I was proposing that collaboration between testers and
developers with automated regression tests is a good
way to go. If the goal is change detection, an
effective way to approach it is through different
automated testing techniques. Instead of just trying to
automate the manual regression tests, development
automated unit testing and other automation efforts
have the potential to compound each other.
The change detection concept really seemed to help
people get a consensus on why we should be automating
these sorts of tests instead of just "automation ==
good". It really came in handy.
(Posted with permission.)
P.S. I'm told that
Cem Kaner coined the phrase "change detector" at
Agile Fusion. The idea has been widespread, but as the patterns people
know, a catchy phrase matters a lot. Here we have one, one that I at
least don't remember hearing before.
## Posted at 06:17 in category /agile
[permalink]
[top]
|
