I want to get back to my thoughts on patterns as a test design technique. There’s a lot to be learned conceptually from the design pattern world. The design pattern template as defined by “the gang of four” in Design Patterns includes the following criteria:
Pattern Name (scope, purpose)
Also known as (other names)
Participants and participant’s names
Sample code and usage
With a bit of tweaking, the list above could be applied to test design techniques (the tweaking would primarily involve adding additional criteria).
Although there have been several papers and articles on software testing patterns (e.g. the DeLano / Rising Test Pattern Language, and everything Brian Marick at testing.com has done), I always refer to the template created by Bob Binder in his Testing OO Software book as a starting point. Binder’s template for test design patterns looks like this:
Name - a word or phrase that identifies the pattern
Intent - what does the pattern do
Context - when and where do you use this pattern?
Fault model - what kinds of faults does this pattern expose. Why does it expose them
Strategy - how is it implemented (often includes example)
Entry criteria - what are the preconditions
Exit criteria - how do you know you have finished testing with this pattern
Consequences - advantages and disadvantages of using this pattern
Known uses – how has the pattern been used before
Related patterns – are any other patterns similar or complementary
Rather than take the time to go into more detail on how this template is used, I will refer you to the RBSC online article index which includes a catalog of 37 test design patterns, as well as full examples for the Category-Partition pattern and the Extended Use Case pattern.
I have a ton or respect for Binders patterns, and I think they are the starting point for anyone interested in test patterns. Recently, however, I have put some thought into a different template. I’m still playing with it, but I’ll run it by the two dozen of you who put up with my random ideas later this week.