SWE 437 In Class Exercise #2
Modeling for Testing


Names:

Instructions: Work with your neighbors in groups.

This exercise touches on many of the topics we will address this semester. Don't be concerned if part of this exercise seem "fuzzy" now; by the end of the course, you will understand why I put each of the questions into the exercise.
Consider the following whimsical example:

If the moon is full and the sky is clear, release the monster.
If the sky is clear and the wind is calm, release the monster.
  1. What important thing should not happen while testing this system? What implications does this observation have for building test environments for real software?


  2. Formalize the input domain as simply as possible. How can you develop tests from this model? If the input domain model is more complex, does this approach still work?


  3. Build a graph model model that captures the logic of these requirements. Create a minimal set of tests that "cover" the graph. How many tests do you get, and how satisfying do you find these tests?


  4. Build a logic model that captures these requirements. How many different test cases are possible, and what is the outcome in each case? Again, make the simplest possible choices. As discussed last time, testing each possible case is probably not the best approach - at least not for large numbers of boolean clauses.


  5. Develop tests that target each boolean clause. Would you expect to find more problems than those specifically targeted by your model?


  6. Model what could go wrong from a programming perspective. There are multiple possible answers. For your model, is it possible to target test cases specifically at what could go wrong? Would you expect to find more problems than those specifically targeted by your model?