Formal QA Education - do we need it

I recently attended a conference regarding a new release of the HP Quality centre product.

One of the guest speakers was a person involve with ITCB organization.

The ITCB organization is the Israeli branch of the international ISTQB the organization is involved with certifying QA testers. and in trying to set criteria

• which will mark the level of QA engineers.
• Create a common language used by all.
• Provide QA with tools and skills to perform their jobs more efficiently
  
• grant official and formal acceptance if the QA as a credible occupation

after we returned from the conference an argument arose between us in respect to the actual need for such an organization and what are the advantages and dis advantages of such a certification.

On the Pro's side we noted the main goal of a formal language and developing better personal testing capabilities which young testers tend to lack.

On the Con's we were concerned that this course / certification will become mandatory and therefore block acceptance of otherwise capable engineers for QA positions

My opinion is that the general idea is sound and will contribute to QA professionalism where ever implemented and may put an end to low opinion of QA personnel which I mentioned in one of my previous blog's .

How ever I think the certification should be a part of the training and not a a threshold factor preventing the acceptance of otherwise capable engineers.

I can testify from personal experience that most of my QA team where technically capable people which were mentored and bloomed into good QA engineers.

Further to this from the following diagram

We can see that Quality Assurance skill are only part of the makings of a good QA engineer.
To conclude I think this is the proper way to approach this rather than using the certification as a filtering tool

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...

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.