Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


Please Note: User Stories are not a part of Scrum. User Stories are just one technique among many (Use Cases, Prose requirements, Test Scenarios, etc)to implement Product Backlog Items within Scrum.

Basic Story Testing Styles


Summary

In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as "User Story Acceptance Tests", "Acceptance Tests", "Acceptance Criteria", "Confirmations", and "Test Confirmations." In this article, I list the most basic styles for expressing Story Tests:
  • Style 1: Bullet Points
  • Style 2: "Test with..."
  • Style 3: "Test that..."
  • Style 4: Given/When/Then
  • Style 5: Specification By Example - Conceptual Form
  • The Best Style: Mix and Match!

Reminder!

No one should ever interpret styles for expressing Story Tests as a documentation technique. It is a communication technique, and the expression of tests should be the *results* of ongoing collaboration. Expressed tests should only serve to support the collaboration, as well as retain the knowledge just long enough to test and deliver the Story's functionality. Expressing Story tests is a means to end. The "end" is not documentation or a strict contract. The "end" is team and stakeholder understanding, as well as communication efficiency. In addition, ideally, these tests get automated, so the end state of Story Tests is an extensive test suite that also documents the correct system behavior for many years or decades into the future.


Said another way, let us not forget that we value "Working software over comprehensive documentation" and "Individuals and interactions over processes and tools."


Style 1: Bullet Points


Description
  • Jot down bullet points on a Story card or a Wiki to remember what the actual and expected system behavior is.
  • Because this is a shorthand notation, team conversation context is extremely important. Said another way, you the reader of this article, may not get a lot out of seeing the below bullet point examples, because you weren't there for the conversation and its associated context.
Good for
  • Small Stories, where the effort involved is ~2-3 days(which is the recommended size for Sprint Level User Stories).
  • Tests that are somewhat obvious (in the example below, the old password obviously needs to match what's on file)
  • Tests that the team will likely remember anyway, so they only need to jot down simple reminder notes.
Bad for
  • Tests that are not likely to be remembered later by the team just reading bullet points.
  • Tests that have logic or complexity that might be forgotten.

Example Tests
  • old password
  • new password
  • confirmation password (must match new pw)
  • new password complies with password rules

Style 2: "Test with..."


Description
  • Jot down notes about what scenarios and/or data to test with.
  • Because this is a shorthand notation, team conversation context is extremely important. Said another way, you the reader of this article, may not get a lot out of seeing these example tests, because you weren't there for the conversation and its associated context.
  • Optionally, start the test with "Test with..."
  • Optionally, add a "...verify..." clause

Good for
  • Small Stories, where the effort involved is ~2-3 days(which is the recommended size for Sprint Level User Stories).
  • Simple tests.
  • Tests where the expected behaviors/outputs are fairly obvious
  • Tests where the expected behaviors/outputs are simple (generally only happy/sad paths)
  • Tests that the team will likely remember behaviors/outputs anyway, so they only need to jot down some data scenarios to create the different expected behaviors/outputs
Bad for
  • Tests that are not likely to be remembered later by the team just reading simple "Test with" notes
  • Tests where the expected behavior is not fairly obvious
  • Tests where the expected behavior varies a lot by data scenario
  • Tests that have logic or complexity that might be forgotten

Example Tests
  1. Test current password with incorrect, correct, blank
    • with optional "verify" clause
      • Test current password with incorrect, correct, blank - verify error msgs
    • with optional beginning of "Test with"
      • Test with incorrect, correct, blank current password - verify error msgs
  2. Test with special characters in current password
  3. Test confirmation password with blank, matching, non-matching
  4. Test with admin users, manager users, end users
  5. Test with 0, 1, 3, and 5 companion products

Source
  • User Stories Applied (Cohn)


Continued - More Styles



coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg