I was talking to someone the other day and where I derive my test cases from. This is an encapsulation of that discussion.

  • Requirements – First and foremost, the software must do what the client is paying for and/or the market is demanding. If the requirements are not met, then you cannot say that the project is delivering what it should. Of course, when the requirements are not adequately flushed out or are being actively discovered during the course of development all bets are off, but the requirements always form the basis of test case suite.
  • Standards – Standards tend to be implicitly included in the requirements. It is unlikely that medical systems software explicitly calls out that they must be HIPPA compliant. Similarly, if you are storing CC numbers you are expected to follow the industry guidelines for their storage.
  • Usability / Accessibility – Another area of implicit requirements is around usability. The requirements are not going to say “Must be easy and convenient to use.” The lack of inclusion does not mean that it “Must be horrible and inconvenient to use.” This is stuff like tab order, font resizing, colour contrasts, etc. It also means that user friendliness is what I expect. For instance, it is much better to prevent an action up front by constraining a field than pop up a box later saying the user put in too much information.
  • Risk – If an area has a higher chance of being buggy, or if bugs in a certain area have an outweighed effect on the system, I look at them more.
  • Storage – Most systems these days have some sort of storage component be it a database, flat file, LDAP or whatnot. All these systems have better (and worse) ways of interacting with them. In the case of database storage I look at things like referential integrity, degree of normalization, appropriate audit trail, triggers getting fired when they should, etc.
  • Logs – Logs tend to provide a fount of information. If you spot a stack trace in a log, then there is an area to be explored and usually if there is one stack trace, there is another lurking in there as well.
  • Source Code – While you don’t have to program to be a good tester, I think reading code is absolutely essential. Without knowing how to read it would you know that a particular has 5 code paths when you can only trigger 3.
*Past Bugs* – Nothing annoys customers more than fixing a bug that they found, only to introduce it back into the code base in a later release. Hopefully the developer who fixed the bug also put in a unit test for it, but if not then it needs to be retested.

There is more I’m sure, but that is all I could come up with waiting in the doctor’s office this morning.