When working on a new functional area, there is usually (hopefully?) a period of time during development where the functional specification is in a usable form, even if the software is not in testable state. The spec might have a high level description of the functionality to be implemented, and some sample screenshots of what the finished UI will look like, but it can be a bit of pain to weed through what a developer has written to find what will eventually become test cases, particularly if your methodology focuses on black box testing and the developer has included a lot of implementation details.

One of the methods I use to get a quick outline of potential test cases is the same method that SAT prep courses use for the reading comprehension section of the test. By quickly skimming through the text, looking for specific trigger words, one can quickly glean what’s needed. In the case of the SAT, the triggers are words like because and after. In the case of a functional spec, the trigger words are words like if, when, and, or, and otherwise. These are words that, not surprisingly, have a direct correlation to codepaths. Take a look at this short example:

If an object has been published in a library, it will appear when the user searches the database.

You find the if, you find yourself two test cases. One, that published objects appear in a search. Two, that unpublished objects do not. Here’s another one:

If an object has been published in a library, and the user has rights to search that particular library, it will appear when the user searches the database.

Now you have three test cases: the original two, and a third where the object is published, but the user does not have the rights to search that library.
It doesn’t matter what the mechanism is for searching or for publishing… those details can be filled in when those first usable builds are available.

Bullet points can also be useful - they often provide a list of testing prerequisites or verification points. Here’s an example:

When a user logs onto the system, they are greeted with a welcome page containing the following:

• The current date and time, with timezone
  
• A list of objects that have been published since last logon
• A list of tasks assigned to them
• An inbox with messages from other users

Now you have a list of verification points to check upon logon. Again, it doesn’t matter what the UI looks like… the details can be filled in later. But you’re building the skeleton of a test suite rather quickly without the software, and without even digging too deeply into the functional spec.