thoughts from the test eye

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.