Soap Opera Testing

Test processes are successful if they are effective, efficient, manageable, and fun. A major factor in how well these four objectives are achieved is the approach to making test cases. One such approach is "soap opera" testing.

As many readers know, soap operas are dramatic daytime television shows that were originally sponsored by soap vendors. They depict life in a way that viewers can relate to, but the situations portrayed are typically condensed and exaggerated. In one episode, more things happen to the characters than most of us will experience in a lifetime. Opinions may differ about whether soap operas are fun to watch, but it must be great fun to write them. Soap opera testing is similar to a soap opera in that tests are based on real life, exaggerated, and condensed.

The idea for turning test cases into soap operas came to me while testing a new financial system. A group of end users was mobilized to come up with a large number of test cases quickly. It was important that the test cases be very good and very aggressive, even though time was limited due to extra pressure from the potential Y2K problem. Because the system had to do sensitive work such as calculating pensions for retirees, errors were a big no-no.

The end users were the people with the most practical knowledge, but they had no IT or QA background. The testers lacked the proper financial background and the day-to-day experience. To solve this, the testers and end users were asked to sit together in small work groups (four to five people each) and come up with stories based on the most extreme examples that had happened, or that could happen in practice. Imagination was invited and exaggeration was welcome. To help the process, I asked the groups to imagine that they were writing soap operas. This helped create lean, mean test cases fast. It also made the whole experience a bit more fun, which was important in this situation, where end users had to put in a lot of time testing—something not in their job descriptions.

Mechanical Approaches to Testing
To set the stage for soap opera testing, I want to contrast it with the more common ways test cases are usually made, which I call the "mechanical approaches."

By a mechanical approach, I mean developing tests following a simple, prestructured process. For example, consider the following process. Start with a finite number of screens or requirements. For each screen (or requirement) in a system, make a test case that inputs values in that screen. After entering the values for each screen, verify that those values appear in the system. Then, check whether the system has caught illegal input, such as mandatory fields that haven’t been filled in. If the above tests are completed successfully, testing is complete.

These tests may be developed "top down"—break down functional specifications and/or requirements until the items are elementary enough to create tests for them. Or they may be developed "bottom up"—make one or more tests for each small unit in a system, then organize those tests into larger suites. These are analytical ways of thinking, common for IT people. For testing, however, a better direction is what I like to call "outside in"—work from the business environment toward the system under test. This is the essence of soap opera testing.

I'm not saying that mechanical approaches aren't any good. On the contrary, mechanical approaches tend to be straightforward and give reasonable confidence that the functionalities in the system under test are in good enough shape for normal, everyday