Testing dojo session 7 - Scenario testing part 2 - boring

In this session, we continued with BBST video lecture / scenario testing part2.

Doctor Cem Kaner started by introducing how he met Hans, a weird but good tester, and how Hans considered Soap Operas as "the boundaries of life". I guess "Soap Opera" is something like "Friends" or "Growing pains", where several major characters get together, break up, and together again. In Friends, Ross has already devoiced 2 times, and yet, he devoiced, again, the 3rd time. You never know what might happen next.

Back to the lecture, Doctor Kaner demoed several ways to create a "soap opera" story:

• set extreme value to variable in a story
• repeat steps many more times
• create a hard to survice environment

It reminded me 1 old bug. I was testing a component which collected a list of files, I asked developers, "what's the limit here? how many files do we support?" "As many as users want, we do not set limit for that.", they replied. I created 200 files, and it failed. "No body in real environment would do with that many files." Developers explained. A few months later, a customer reported the same bug. Error log showed that he was trying to input 902 files.

Then Doctor Kaner listed 16 ways to create a scenario.

• create a mock business, treat it real and process its data
• try converting a real life data from competing application
• list possible users, analysis their interests and objectives - I develop this one by myself without watching the video :-)

I love these 3 because after domain testing and function testing, they could still reveal something new about the system and customers.

In the end, Doctor Kaner reminded us the limitation and risks of scenario testing.

• hard to maintain cases
• not good at reveal coverage
• should not be executed before domain and function testing

After the lecture, we moved on applying scenario testing with an in-class-activity assignment - "select 1 way from 16 and apply it to create 3 scenarios". The number was overlooked, which was a big mistake, and we started creating one scenario after another. The more we created, the more boring it became. We couldn't stop because we were not sure if we finished it, and we couldn't continue because we didn't know where this was going.

To kill this boring part, I decided to switch this dojo to a rounded dojo, each tester contributed an example on how the 16 ways could help to test their current project, we passed the ball around the room and every one was contributing. After several rounds, we shut this session down.

One good reason for the rounded dojo is to keep everyone involved. And figuring out how to apply a technique, coming up with an example is one of the best way to make sure people understand something.

If you organize your own dojo some day and suddenly boring shows up, I suggest you try this.