Work backwards from a destination
Many of us are comfortable testing from a use case. It's familiar. Most of us are trained and experienced in thinking about a problem starting from an actor, who takes action, and ends up somewhere. It's the classic "Given... When... Then..." way of thinking about a problem. You start from point zero, then advance to the destination. Lately I've found it helpful to instead start from the destination, and then work backwards from there to think of all the different ways I could end up there.
For example, let's say I'm on a search results page. Here are all the ways I might have gotten there:
This technique is sometimes helpful when the piece of functionality I'm testing has preconceived notions about what defaults it can assume based on how the programmer thinks I got there. They were likely thinking of the one or two use cases they had available - not the 8 or 9 other ways you can get there.
For example, most features on search results page (like sorting, filtering, etc...) assume you've entered search criteria. In some cases, that's just not true. Sometimes you can get to a results page without entering anything. If your search criteria isn't pre-populated in the search field for you, in those cases you can get some really odd behaviors. This can become even more interesting when you're dealing with features that perform calculations, or where the issues resulting from the false assumptions aren't immediately visible.
The next time you run across a feature that looks like it might be making some assumptions based on state, work backwards from that point to think of all the other ways you might be able to get there. Do all of those paths lead to the necessary conditions for the defaults to be populated? If not, what possible problems might that cause?
For example, let's say I'm on a search results page. Here are all the ways I might have gotten there:
- I go to the search field on the homepage, enter search criteria, I land on the search results page
- I enter a URL someone sent me which takes me to the search results page
- I click on a link with a hard-coded search request that takes me to a search results page
- I click the back button on my browser which takes me to a search results page
- etc...
This technique is sometimes helpful when the piece of functionality I'm testing has preconceived notions about what defaults it can assume based on how the programmer thinks I got there. They were likely thinking of the one or two use cases they had available - not the 8 or 9 other ways you can get there.
For example, most features on search results page (like sorting, filtering, etc...) assume you've entered search criteria. In some cases, that's just not true. Sometimes you can get to a results page without entering anything. If your search criteria isn't pre-populated in the search field for you, in those cases you can get some really odd behaviors. This can become even more interesting when you're dealing with features that perform calculations, or where the issues resulting from the false assumptions aren't immediately visible.
The next time you run across a feature that looks like it might be making some assumptions based on state, work backwards from that point to think of all the other ways you might be able to get there. Do all of those paths lead to the necessary conditions for the defaults to be populated? If not, what possible problems might that cause?