Yesterday during my keynote at the Agile Testing Days 2012 I said I see a lot of standups, where testers report on their yesterday’s work in the following way:

Yesterday I tested the thing with the stuff. I found some bugs, and filed them. Today I will test the foo with the bar.

I think this is horrible test reporting. While concluding the fifth beta of Elisabeth Hendrickson‘s upcoming book Explore it! I found a few more hints in the same direction. On the same line I will relate good test reporting during the standup to what for example Michael Bolton talks about when it comes to test reporting – we should tell three stories during test reporting:

• a story about the product
• a story about testing
• a story about the process

The story about the product

During a daily standup you will not only find programmers longing for feedback on their hot new stuff from yesterday’s hard day of work. There is likely to be a ProductOwner, and maybe even other stakeholders of the product that you build. As the purpose of the daily standup is to coordinate the team’s work, for the team to coordinate their work, it needs to have as much information as possible to make the right decision for the day. Therefore it needs to know whether you as the tester found so many bugs in that critical new area that your sprint goal cannot be fulfilled in the remaining five days, or whether that new feature works out sharmingly on your desk, The ProductOwner might need that feedback to prioritize the remainder of the product backlog, and the programmers need to be able to know how whether Pete has to work on these bugs, or whether he can start working on the sixth story in your iteration.

Therefore you should have a story prepared that you can tell about the product the particular area you have worked on yesterday, and what you think needs more exploration for tomorrow. If you do exploratory testing and schedule your debriefing right before the standup, it will be an even easier job to do. Don’t overwhelm your team and ProductOwner with too many details thought make sure to raise the major issues at the standup, and maybe ask for more one-on-one discussions later where more minor issues occurred.

The story about the testing

A good self-organizing team shold be able to overcome most of the obstacles that it encounters. As a programmer, when you hit the problem of loosing yourself in someone else’s code because it is too complicated, you will make the decision to pair up later during the standup. The same holds for the work of a tester. When you find yourself painted into the corner, your team does need to know it in order to coordinate in a way that you get the support to deliver even more awesome testing for tomorrow.

That is why we also need to tell the story of our testing, how hard it was to setup a test, and whether maybe a better logging functionality could help improve the results that we can deliver. If a programmer finds out, that he could do most of the puzzling tests on a unit test level, you might even be more impressed if you paired up with him in order to find the right examples and checks and automate away some of your more tedious tasks for the future. You might also find out that your ProductOwner can reveal more details about the limitations of those acceptance tests for story xyz, that you automated yesterday, and you can have a meaningful discussion with her about that. The team might be able to help you support you in work – especially if you feel desperate because you feel you didn’t achieve anything due to these issues.

The story about the process

That leads to the final story, the story of the process. At some teams I find that issues in the team itself are withheld until the retrospective at the end of the iteration. Don’t do that. Instead provide what bothers you. If you don’t feel safe enough to talk about the problems that you face, your team might suffer from the lack of trust, that Patrick Lencioni refers to as the basis for great teamwork in The Five Dysfunctions of a team. Trust is the founding basis for great teamwork. That is why you should be able to talk about the problems in your process, the desperation that you face, and come up with short-term solutions to fix that. Don’t withhold this useful information until the retrospective in two weeks.

The story about the process includes for example that you were waiting for that first story since yesterday, but it couldn’t be finished Maybe your team decides that you as the tester should support the unit testing of the programmers so that the feature will ship in better quality for exploratory testing later, and that you will have some information about what your programmer already has covered in their tests, and consciously decide which other tests to skip for this iteration. Maybe you find out that there have been too many ambiguous acceptance criteria for that critical story, so that you are now fleshing out all of the details too late. Then you might decide to call in a speculation specification meeting to bring these ambiguities to the table, and clear them now. Leave the experiment to run these specification workshops more regularly for the retrospective meeting, maybe, when you have empirical evidence how these worked out.

So, at your next standup meeting, prepare these three stories: a story about the product, a story about the testing, and a story about your process. Your team will be able to coordinate better with this useful information.