The most interesting tests poke at a couple of features at a time. For example, take Call Forward when Busy and Call Waiting. When CFB is active, does CW happen? If so, does caller D get forwarded when he calls A who is already talking to B and C in a CW call?
Does the call get forwarded properly when CW is active?
Bonus points for the devious test case that has A configured to forward to B… or D.
You’re more likely to see failures when stacking features like these. This is because the individual features have only been tested in isolation. They were probably also developed in isolation, so they may not be robust to unexpected twists in the call flow.
Often the “expected behavior” for a stacked test case is hard to define. Sometimes we don’t really care if the call is simply dropped or provided with an error tone — we just don’t want any lines to get stuck in a bad state.
Other times the specs provide a clear definition of what should happen in a given situation.
Or maybe you have a case where you want to ignore the spec and provide a special outcome. (E.g. avoid dropping / error-toning a call in favor of transfer to an operator — this may be more profitable for the end user.)
Defining these stacked cases isn’t hard, “expected behavior” decisions notwithstanding.
Pick the main feature you’re testing. Pick a step in the happy path call flow. Consider what sort of mayhem you can induce by doing something crazy to one of the participants: an inbound call, an unexpected hang up, hook flash to initiate a new feature.
Once you have the “vanilla” happy path test script working, you can use it as the basis for several stacking scripts with just a little extra effort.
The most interesting tests poke at a couple of features at a time. For example, take Call Forward when Busy and Call Waiting. When CFB is active, does CW happen? If so, does caller D get forwarded when he calls A who is already talking to B and C in a CW call?
Related posts:
