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...
2009-03-01
Testing Plans - Optimal vs. Real life
Up Until now I have discussed what we should strive for in the QA.
How ever one must bare in mind that there is a difference between an extensive testing plan and its actual implementation.
One of the best signs for a QA maturity is the ability to prioritize and plan a head taking into consideration the feasibility of an actual test plan.
In the normal flow the QA engineer will map out the entire test plan covering all the little bits and pieces needed to be tested.
The QA team leader will then take the raw plan and organize it according to time table limitations.
This re-organization can be consisted solely from re shuffling the tests order to allow a better , more effective release picture in a shorter time.
How ever in some case a little more joggling may be called for when the time frame needed for a full test cycle exceeds delivery commitments.
When faced with the second option we as QA will need to perform some risk assessment in order to consider which parts of the tests can be dropped.
The risk assessment process is a very critical phase since it calls for an ability to see the whole system ... a wrong assessment will lead directly to system problems on the costumer system.
The risk assessment can and should involve others except the QA team leader.
In any case the tests which were dropped and the risks taken should be voiced clearly in order to inform all of the interested parties to the compromises made in the test plan.
How ever one must bare in mind that there is a difference between an extensive testing plan and its actual implementation.
One of the best signs for a QA maturity is the ability to prioritize and plan a head taking into consideration the feasibility of an actual test plan.
In the normal flow the QA engineer will map out the entire test plan covering all the little bits and pieces needed to be tested.
The QA team leader will then take the raw plan and organize it according to time table limitations.
This re-organization can be consisted solely from re shuffling the tests order to allow a better , more effective release picture in a shorter time.
How ever in some case a little more joggling may be called for when the time frame needed for a full test cycle exceeds delivery commitments.
When faced with the second option we as QA will need to perform some risk assessment in order to consider which parts of the tests can be dropped.
The risk assessment process is a very critical phase since it calls for an ability to see the whole system ... a wrong assessment will lead directly to system problems on the costumer system.
The risk assessment can and should involve others except the QA team leader.
In any case the tests which were dropped and the risks taken should be voiced clearly in order to inform all of the interested parties to the compromises made in the test plan.
Subscribe to:
Posts (Atom)
Posts
