Status Reporting Questions Rikard Edgren

Status reporting of testing activities is extremely project-dependent. The needs of when and how and what will differ every time. Maybe that’s why there’s so little good writing about status communication; you have to make it up every time.

Templates are out of the question, and I believe examples will mislead you as well.
You’re better off by thinking around these questions (inspired by final section in Lessons Learned)

Why are you reporting?

Are you giving quality assessments, trying to prove why testing is taking place?
Is focus on the product story or the testing story?
What kind of information can change decisions that are based on your report?

What is most important?

The everlasting and most difficult question for all testing efforts.
This is what you should start your report with.

To whom are you reporting?

What kind of information is the audience interested in?
Are developers the only ones reading bug reports?
Do you have a grounded quality model?

Are you adjusting the language for the audience?

Communication includes making sure it is understood.

In which ways are you reporting?

Just one way is rarely enough; use talking, writing, long, short, formal, informal.

Are there certain times when things need to be communicated?

Project milestones and meetings might need your information.
Some things must be communicated continuously and timely; bringing up bad news on the last day is a very bad idea (but sometimes inevitable.)

Are you using status reporting as a means for new test ideas?

I often start writing an important report early, to identify things that needs more testing.
You should start thinking about the reporting before the testing starts.

Are you reporting just because you are supposed to?

Then you should read these questions again…


If status reporting is difficult, there might be something wrong with your testing.

John Stevenson December 14th, 2011

Interesting set of quesitons Rikard and I agree with most of what you say.

My only reservation is that you make no mention of using dashboards for reporting. We have a basic template for this which allows the person reporting to adapt and change to suit their needs.

Also currently we are looking at using mind maps as a test plan and as a dynamic test report which resolves the issue of what to report.

Rikard Edgren December 14th, 2011

Thanks for the comment John; now dashboards are mentioned;)

I don’t want to include format, because it will narrow the options.
Dashboards are aimed towards giving an overview quickly, which is appropriate for some projects, some people and some situations.
Drawbacks I see is that a comments field with the most important information often isn’t used, or read.
But if it works well for you, great!

Mind maps are great, but especially for the persons that created it.

My personal favorite for testing communication is face-to-face talk.