Version Releases - how do we make it comprehensible

One of the most obvious tasks the QA is responsible for is the version release at the end of the testing cycle.

First let me emphasis that I do not believe that the version release is solely under the QA's responsibility the release process is a lengthy process starting with the designer/ programmer and ending with the QA.

Next we must bare in mind what is the purpose of the release meeting?!?

I believe that this meeting is intended to provide a "Version Status Report" to all the relevant share holders, for example :
R&D Manager
Marketing / Sales
Project Managers
..

It is point less to expose the extensive list of people to a dry list of bugs and descriptions.

I believe it is up to the QA to make a clear presentation of the version status.

For example instead of presenting a table listing bugs , the first page in the presentation should be a "Grade" of sort to the version;

Version is GOOD , MEDIUM, BAD ... we can even colour code it for better presentation for example

GOOD will be marked in GREEN
Medium will be marked in ORANGE
Bad will be marked in RED

Those grade can be discussed and agreed upon in advance where each grade will be related to a certain amount of bugs, e.g.;

GOOD = 0 "Show Stoppers", X "High", Y "Medium", Z "Low"
MEDIUM = ...
BAD = ...

management will first get a certain idea as to the version quality.
and then if they wish to get more details they can drill down and see
...

Before going any further I'd like to discuss the platform on which we present the release ...

While I may be breaking some sort of TABOO I do not think word / any other form of document is the way to go.

I think web interfaces will serve us better providing better clarity and flexibility.

The Whole idea revolves around the concept of trying to avoid data overflow.

I believe we should not expose all the data flat out since it will confuse the higher levels of management.

I propose using hierarchical rather then flat description.

This is easily achieved using web pages.

The main page will contain a table with a list of the released Base Lines along side their grades.

Each BL will be a link allowing to view what is the BL content and what are the elements making up the grade (number of bugs, coverage rate)

Each number of bugs will be a link to a table listing what are the bugs exactly .

Last but not least each BL should have a version delta page listing what new features were added between the last released BL and the new one.

For Complex Systems a Components Table should be available detailing the different component versions and if needed installation instructions pages.


To be Continued...