Anything revolutionary happening with the status reports? Martin Jansson
I seldom see discussion about our status reports. I refer to the reports that we write for the release, iteration, build and so on. There are several templates and standards out on the internet but I have not read any ground breaking updates in that area for a long time. Many might see the status report as a minor part in what we do and that it should not get too much space in our discussions. It’s the actual testing that is the most important, but I still think it deserves some thought.
As I see it our status reports reflect both facts and feelings. One of the goals is to give the stakeholders as much information as possible to make decisions regarding quality. I have read many status reports that sometimes, as I see it, lie about the situation. Examples of these lies can be that the writer tries to gain respect by exaggerating about certain areas and can sometimes suggest not releasing just because of an internal project vendetta, and so on. Naturally this should never be the case, but I have seen it and I’m sure others have as well.
It is hard to write about status. There are so much that can be included. So, perhaps we could learn more from similar professions that write reports such as these. The professions that I think of first are film critic and food critic. Both of these are preferably experts in writing the status reports, either for a film or a something related to food.
Anyone have further ideas how to perfect our status reports?
I agree that there is little discussion about the status report.
But I don’t agree that film and food critics should be seen upon as role models for a Status Report Writer (SRW).
I believe that film critics and food critics are almost 100% subjective when they write their reports (it is their taste that matters). And I believe that the problems with the quality status reports is not that they should be more subjective; rather it is the objectivity that should be improved if we want to provide decision-makers with proper information.
As you describe it, people lie in these reports. It might not be lies on purpose, but a simple case of being biased when writing; and the selection of words and subject will be colored and selected based upon the subjective feelings of the SRW and what the SRW thinks is important, ugly, nice, etc.
Though testers could strive to make testing to be performed with a subjective approach, the status reporter should strive for a more objective and unbiased approach to status reporting.
My tip on how to improve your critical thinking and analysis skillls (and thereby improving your objective reporting skills; as well as your subjective testing skills) is to read the great book “Tools of Critical Thinking – Metathoughts for Psychology” by David A. Levy. It contains 30 metathoughts that arise from critical analysis of the way we think.
Super tools for testers! And status reporters!
Also, we could learn from researchers on how to report and present information in an objective fashion.
It might be so that the properties of a good tester might be contra-productive when it comes to good solid status reporting? And similarly that the properties of a good SRW might protect you from doing a great test job?
It is a matter of switching hats; and to be able to do that properly, one must know which hat to put on.
For a glimpse of the metathoughts mentioned before, see http://waveland.com/Titles/Levy-TCT.htm
Yeah, it is interesting that there is so little discussion and information about status reporting.
I guess one reason could be that the importance of things differs so much between companies.
And I agree with Henrik that different skills are needed for testing, and for status reporting.
But should testers really be the ones writing quality status reports?
It’s also difficult with the objectivity/subjectivity distinction, since everything is tied together.
One way to think about it might be: A good quality status report is objective about subjectivity.
A common problem I have seen is that it is difficult to get people to read the whole status report, so the worn-out cliché “less is more” could be appropriate.
But in that case there is a risk that some objective numbers without knowlege about details gives the wrong impression.
Testing is difficult, and status reporting as well.
Rikard, regarding your point “…it is difficult to get people to read the whole status report, …”:
One improvement might be to try to make sure that any information entered in the status report is interesting or important to someone. Which means that all information has a purpose and a recipient.
A problem with this might be to know exactly who cares about the information; how important this person is; and how detailed this person would like the information to be.
I think it might be reasonable to create two status reports: one brief and another more detailed, actually it could be the same report if it were possible to hide fields of text!. The report would then be presented with a drill-down approach. This way you could get a status report that reaches out to more people, but tailored to each stakeholder and their needs.
In some cases I know which people I’m writing the report for. In these cases I have been able to ask them what they want to know and read about. It seems like these reports have been a lot more popular than producing the “template status report” and just giving out standard information.
Still, there is some information that always seem to be interesting to put in. I guess it would be good to “template” that information.
A good thumb rule is also to keep the documentation to a minimum, to spare the world from too much information that noone cares about.
I will try to delve deeper into the project into making the ultimate status report.
I will see if I can make a up-load-component available at http://www.thetesteye.com so that they can be stored as well.
Hi,
What about a testing dashboard?
http://abouttesting.blogspot.com/2008/06/testing-dashboard.html
/Stefan
http://abouttesting.blogspot.com
Hi Stefan,
I like your dashboard! Need to try it out!
Though nothing beats the whiteboard for these kind of dashboards…
But it is harder to distribute a whiteboard to stakeholders, so your app looks promising.
/Henrik