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.