I participated couple times for sprint planning meetings that one of our development teams is arranging. One thing that bothered me, was that there wasn’t much discussion about how the next sprint stories will be tested. This discussion came later when domain experts gave feedback after familiarizing with implemented story. I felt that the feedback came too late this way and that it would help to improve the quality if we could diversify the discussions before we start to implement a story.
Writing test notes
So I came up with an idea (which I’ve tried out earlier when I was consultant and originally learned it from an Atlassian blog post) that we would explicitly think about testing during the sprint planning. Then we would write down separate test notes for the story in our JIRA. It could look then something like this:
At the moment I have a separate meeting on the same or next day than our sprint planning. Developers, PO and domain experts (domain experts are the testers in our case) participate to this meeting. We go through all of the stories that we are going to implement on next sprint. While doing that we ask
How are we going to test this?
We also think what kind of test data is needed. Or what kind of cases could introduce problems to this implementation. In many cases the developers have come up with good ideas on what kind of special cases might be troublesome.
So far these sessions have provided value by being able to catch troublesome cases before the stories will be implemented. There’s also been occasions where we’ve realized that additional requirements need to be specified because we haven’t considered a scenario that could take place after story has been implemented.
I’m planning to continue making these kind of sessions as a habit for this team. Future retrospectives will give also ideas on which kind of modifications are required to further develop these to suit this particular team better.