Acceptance Criteria : it’s a good friend

With some careful planning, a good use of time and access to your customer (or customers proxy) you can craft and distill stories that will make your job as a tester all the more effective.

 

On an agile project test involvement early in the planning and story writing can add an extra dynamic. Testers often have very critical minds and often ask questions other team members don’t. And it’s this questioning and thinking that is so powerful and effective when writing stories.

 

It’s not just that the customer understands the stories more and thinks more critically about them but that the programmers also have more information up front and the designers and any other team member can see clearly what criteria that story will be judged against. Testers often posses the skills needed to bridge the gap between the customer and the tech teams too. They also tend to put themselves in the shoes of the user, consider usability and accessibility and are often the ones who raise pertinent questions about non-functional behaviors.

 

Leaving the tester out of the story writing sessions means that when the story moves over to test for testing the testers will often generate a lot of defects, some of them often quite simple. Defects that could (and should) have been found before any code was written.

 

And if the tester is being involved to their full capacity they too will find that the story in essence becomes a very effective test case. A case that both manual and automated testers can work from. There is no reason why a story can’t contain a long list of acceptance criteria. In fact, the more the merrier in my eyes, it only helps to make estimation and verification easier. There’s no reason why the acceptance criteria can’t reference or jump out to flow diagrams, state transitions and any other supporting documentation. And all of this become far more possible when you include a critical thinker in story writing sessions.

 

I’ve been through many sprints that, at first, weren’t successful but we soon started getting key team members involved at each story writing session and we soon started dropping code that had fewer defects. With fewer defects velocity tends to go up, moral remains high and more time is freed up for exploratory testing.

 

So don’t be shy. If you are not actively being invited to story writing sessions, then invite yourself and add your critical thinking early.

4 thoughts to “Acceptance Criteria : it’s a good friend”

  1. Plus ca change..nice to see that though agile differs, it still benefits from early critical testers..Txs Rob

  2. Absolutely. Any methodology, project framework or ‘way’ of working will benefit from early test involvement. I find in an agile world though without that early involvement the later parts of the sprint can often become tangled, confusing and rushed. In essence, the dreaded mini waterfall cross hybrid of doom….ThanksAnne-Marie.

  3. I agree, us testers need to be involved right at the start. In fact, at my previous place of work, the testers actually write the user stories, which include conversation and acceptance sections. This works extremely well and something that I’m pushing for with my current employer. Check out my blog on agile testing http://www.testertroubles.com. Also check out my bosses blog post on the subject who implemented this process. http://www.agile-software-development.com/2008/06/putting-analyst-into-software-testing.htmlRay

  4. Thanks for the comments ray. We also write our user stories with the customer and it works peachy. It’s such a great combination that ensures really great coverage, detailed stories and it’s also a good relationship building process.The more the tester can get to know the customers then the more appropriate and purposeful the software *should* end up being.Rob..

Comments are closed.