Test Cases can be categorized a number of ways. The most common being whether they are positive (check something that should succeed) or negative (a failure in the system is a success in the test). That’s all well and good, but limits your thinking somewhat. I tend to think of things in terms of paths. The notion of a path is nothing new, but I have extended it a bit.

  • Happy Path – These are your positive tests. They provide good data, in the correct order, on the correct screens and will likely allow you to sign off on a good proportion of your requirements.
  • Sad Path – As the name suggests, these are the opposite of happy tests. Your sad tests should cover all the validation and error handling (in all layers of your application). You are going to have to look at the code to know whether you have got all these conditions, though a coverage tool might help. Remember though, that coverage tools will tell you 100% if every line has been touched, not if every line has been touched by all ways.
  • Evil Path – This is somewhat of an extension of sad tests, but they derive from people doing bad things to your application. XSS, SQL Injection, removing JS constraints, etc. fall into this category. Try to think like both the average DefCon presenter as well as a script kiddie. While the attacked might be more sophisticated from the former, the later are far more prevalent.
  • Social Path – Things along this path are more specific and start to move away from looking at the software directly and into the larger system it is a part of. In these tests the attack vector (for lack of a better term now) is the system operator rather than the system itself. What sort of things could you get the operator to give to you that they are not supposed to, and is there a solution (hopefully a technical one, but procedural might have to do) available to address it?