Story Testing Patterns


Be sure to remember to mix and combine the patterns as necessary!
You can also download a One Page PDF or view the Story Testing Patterns Presentation that goes along with this summary.

Pattern

Generally Good For…

Generally Bad For…

<“Test that…”>
  • Beginning Story Testers
  • Simple Tests
  • Tests hard to describe using the other patterns
  • Experienced Story Testers that know a better pattern.
  • Tests with a lot of setup logic or behavior logic(try a different pattern)
  • Tests where behavior depends on numerous test inputs
<Given/When/Then>
  • Tests that require
    • a lot of preconditions or setup, OR
    • setup that is important or easily forgotten
  • Tests that have a specific, non obvious trigger
  • Tests where there are few expected outputs
  • Tests that have unimportant/simple/obvious preconditions
  • Tests where there are multiple different inputs and multiple different outputs
  • Tests where a single Given/When/Then only describes one of numerous very similar test scenarios
<Specification By Example – Conceptual or Concrete>
  • Tests that have numerous:
    • Inputs that affect output behavior
    • Outputs/expected behaviors
  • Tests where it’s important to test a lot of different data scenarios
  • Tests where the trigger event is somewhat obvious
  • Any test where it seems like a table would be useful to:
    • describe the test better, or
    • help explore all of the possible inputs and outputs for a test.
  • Simple tests
  • Tests that are more about verifying simple UI behavior
    • For instance – “Test that an error message is displayed when the user enters an incorrect password.”
  • Test where there is really only one input or precondition
<Bullet Points>
  • Teams that are highly co-located with PO
  • Stories that are very small(2-3 days)
  • Tests that are very simple
  • Tests with fairly obvious expected behavior
  • Distributed Teams
  • Stories that are large (which is a bad habit anyway)
  • Tests that are not simple
  • Tests with non-obvious expected behavior
<“Test With…”>
  • Teams that are highly co-located with PO
  • Stories that are very small(2-3 days)
  • Tests that are very simple
  • Tests with fairly obvious expected behavior
  • Distributed Teams
  • Stories that are large (which is a bad habit anyway)
  • Tests that are not simple
  • Tests with non-obvious expected behavior
<Flow Charts>
  • Tests where the flow of behavior is very complex, and easier to represent with a series of successive questions/answers
  • Generally bad for everything else.
<State Diagrams>
  • Tests where a system object can go through numerous (often workflow related) states
  • Generally bad for everything else.

Remember to strongly prefer index cards(5×8), wiki’s, and whiteboards(take photos!) over ALM tools and other electronic documents/tools.

You can also download a  One Page PDF version or view the Story Testing Patterns Presentation that goes along with this summary.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: