Is a Final Release Report a good way to communicate results?

Question

I'm getting ready to release the next version of our software. In the past when the release is ready to go I will send around an email saying "release xxx is done" and include a basic set of release notes as well as where to find the software. The company (we're small) knows nothing about what happened during testing or what shape the software is in, any outstanding bugs, risks, other than it's passed "the chris bar".

Is a "Final Release Report" a good way to communicate this information? Equally important, is this a good way to say I've signed off on the release but with these caveats? Will this transparency be beneficial?

I don't know exactly what a final release report would look like. Maybe a Google Doc or an email. It will probably describe my testing work, the results and might include a list of open bugs.

-- Chris

Answer 1

Particularly in a small company, go to the readers of the report to find out what they need for it to contain.

Usually, people don't want to hear about your testing work, just the results. Those results might include any open, but deferred, bugs. It might include release notes. It might include features added. Etc, etc.

Do others know the definition of "The Chris bar" and what it means to pass or fail? If not, that might be a good thing to include as well.

Answer 2

As is often the case with small companies, it sounds like you're in charge of two distinct roles here: Testing and Build management.

If you were to produce a report with the release, it would be better to go beyond outstanding bugs, and also report on new features that have been added, bugs that have fixed and so on. If you use project tracking/source control software you can usually generate these things automatically.

Really these things should be done before the software is released and agreed with the end user or a representative (i.e. the PM). It's them who have to use the software after all. The Chris bar should be the user bar.

Answer 3

Yes, providing a report/email is a good way to show what was done, that it was done effectively, and communicate any risks that still remain. A couple of tips based on learning the hard way:

• Any negative information should be communicated verbally, and before the release report. This includes failures and significant risks. The final, written report isn't the first time your stakeholders should see this info.
• Put the summary right up front, and all the support details lower in the report. This release passes the Chris bar, lets ship. Then, give the test result summary, list of open bugs, etc. Many stakeholders won't read past the headline, and they don't want to ready a novel (like this answer) to get the summary.
• Alternatively, you could send two reports, one a simple "this release passes the Chris test" and a second, Release Retrospective that shares lessons learned.