Archive for April, 2012

How I Test in a Sprint

Here are some of the things I do when testing in a Sprint that I have found helpful.  Consider them part of the recipe that contributes to a culture of quality, but I would love to see some comments or experiences from you that will help make this recipe complete.

Test the Process – are we doing things that make sense?

  • My basic assumption is that a two week sprint is not a long time, a plan that takes you 2-6 hours to create during planning sessions should be able to hold up pretty well until the end of the sprint.
  • Pre-planning is critical, do you have lead times on hardware / test environments / external software dependencies, do you actually have commitments from key personnel who are expected to be a part of the sprint
  • Are we breaking down silo’s?  Business and Technical decisions that happen amongst only two people OR among the same functional disciplines may mean that information does not flow to the individuals that need to test it.
  • I like to encourage just enough design up front to identify a general approach to solving some business problem, but not so much detail that it hinders exploration and learning
  • Are me or my team members impediments or blocks actually being removed or is lip service just being given to them

Test the Business Value and Acceptance Criteria – are we building the right thing?

  • Do the backlog items have the right level of detail in the acceptance criteria?  When i’m testing, i tend to advocate breaking down work into chunks as small as possible, and as small as I can get away with.  I find that when stories are too big, it leaves large gaps in the acceptance criteria, AND it masks many of the dependencies that need to be flushed out in order to deliver value
  • Did we ask enough questions about the “why” so that we can challenge assumptions and present alternatives that still accomplish the goal
  • Are we vetting information received from the technical experts and solution implementers through the Product Owner when it impacts the business?
  • If nothing else is automated, the acceptance criteria should be the exception.

Test the Delivery – are we building in the right order? Incremental and Iterative

  • Dependencies matter, and so do priorities.  When the dependencies matter, lay out the strategy of execution order.  When you walk away from planning, having a clear plan on your incremental approach, you should consider what iterations are required to deliver business value
  • When teams are working on too much all at one time, it may seem like they are accomplishing alot, but focus does not just apply to having dedicated resources, it also applies to what people are working on, and when they are working on it.  Typically every team member working on different stories at the same time is not indicative of characteristics of a team, nor is it a characteristic of focus
  • Testing is one of the most critical aspects of making a Sprint successful, yet it is amazing how little is understood on how to invest in this area to bring alignment

Test the Technology – are we building with the right tools and infrastructure

  • Internal quality should not be negotiable if the team thinks it is necessary.  It’s important that tests are being developed starting from the Acceptance Criteria / Examples all the way down to ‘SQLUnit’ tests verifying stored procedure functionality and ‘shunit’ verifying shell scripts.
  • I like to encourage Developers to run some of the manual tests, as well as create api / integration tests so that they can have visibility to how technical decisions either contribute to testability or lack thereof.

Test the Measurements – Are we vetting our measurements and are we interpreting them correctly, do we act on them accordingly

  • I like tracking business value instead of tracking hours.  How many stories have been completed at a given point in time in the sprint.  Is the user story i care the most about actually at risk of being completed?  Burning down hours is great, but hours don’t trace back to business value as well as user stories do.
  • Talking about stories instead of hours helps reinforce the focus around business value and outcomes as well as provide better context for decision making
  • I bring up uncomfortable topics in the retrospective as if it is the last time I am going to be heard by everyone AND I press for at least one or two of the action items or improvements be tried out in subsequent sprints.

Share your thoughts


, ,

Leave a comment