Continuing my exploration of the life of a story in agile testing. Part 1 is here.
Each story on the backlog has been defined by the business and the customer. These are capabilities that the customer wants. So the next step is to distill some more information in them in the form of acceptance criteria. These are essentially the markers/gates at which this story will be deemed as complete. It’s a list of things this feature/capability must do.
Here’s an example story using the Software Testing Club:
As a registers user I would like to create a new forum post so that I can start a discussion
And here’s some example acceptance criteria
- User has the option to create a forum post
- New Forum post window has X fields
- User cannot add a forum post without a title
- All error messages appear at X location
- User cannot add a forum post with no content
- Mandatory fields are X
- Optional fields are X
- Title field holds X characters
- Description field holds X characters
- Tags field only accepts tags separated by commas
- Clicking submit will post to the forum board
- Any errors when submitting will be reported to the user
- User will be able to see forum in list after submission
- Tags entered will be search-able
- Other users can view the posts
- etc
You see the point.
If a tester gets involved in the story writing session then the acceptance criteria tends to be more detailed. It’s natural for us to want to question the story early before we get the software and the more we can do that, the more accurate that story will be. There are plenty more to add to that story example above. Think of distilling more information in the story as if you are fleshing out a test case(s). The story is the test case. The acceptance criteria are the tests themselves.
In the early days for me stories would arrive with only one or two vaguely described acceptance criteria. Programmers would code against these and then make the usual assumptions they often have to make. I would get software that didn’t behave how I thought it should and the customer would need to be consulted all the time, assuming they were available. If not, they would get a demo that didn’t appeal and a whole new sprint would be dedicated to getting it right. Time wasted.
With detailed acceptance criteria that the tester, programmer and customer have all agreed on it is possible to avoid this wasted time. Programmers code against it, testers test against it and the customer accepts the software against it. Anything that changes is agreed between all parties and added to the story. In theory, it’s as simple as that.
So this is why it’s important to get involved early and put some test input in to story writing sessions because the questions and ideas you will raise (just like you would in a test case or through exploration) are essential for the success of that story. How many times do you here a programmer or customer say ‘I would never have thought of that’ or ‘You can’t do that, can you?’ – The tests and ideas that generate these statements are the same golden content you need to get in to the story…..and early.
If you are not involved in the story writing session then try to shoehorn your way in. After all, most managers will be receptive to ways to stop wasting time. Any ideas how to avoid bugs in the software is a good thing. If you still can’t get involved then start collecting defects that you are fairly sure the team could have avoided if testers had been consulted earlier. The tester is the one who thinks about how to find breaks, possesses skills that aid bug hunting, has experience and is often the main champion of customers and end users. So to not include testers in story distilling sessions could be a major mistake.