2009-01-07

QA Methodology

Once we have dispatched with most of the preliminaries it is finally time to get to the bottom of QA - Methodology which is directly linked to documentation.
The document trace usually follows along side the product life cycle which I described in a previous blog entry (product life cycle).

Once the Product manager has decided what are the main features for the product/ version he will then release a document describing these requirements called a MRD (Marketing Requirements Document).
Following this document System engineering will usually output an SRD/PRD (System/ Product Requirement Document) - this document will detail what of the requirements is to be implemented and what are the priorities.
the QA in turn will then review this document and start preparation for the testing.

First QA will generate a STP (System Test Plan) this will describe:
  • what is to be tested
  • testing set-up
  • testing requirements (resources)
  • General time table which should correlate with R&D releases
The STP is usually prepared by the QA manager/ Team leader
Once the general STP has been released and approved it is time to get down to the details of the testing. the STD (System/ Software Test Document)
The STD will usually be prepared by the QA assigned to preform the tests.

When the tester has finished writing the document then a DR (Design Review) will be held in order to approve the STD.
we must make sure the following attend the DR:
  • Product Manager
  • System Engineer
  • Developer / Developer team leader
  • QA tester
  • QA team leader
  • Project Manager - to provide costumer related info if necessary.
Once the version is released to QA and testing has begun, upon completion or at predefined time frame the QA tester will issue a STR (System Test Report).
The STR will detail what tests were actually done and from those tests which passed and which failed , for the tests that failed we will include a short description of the fault and list the relevant bug report.

At the end of the test cycles have completed a Release meeting will be called, in it QA will present the last segment of documentation the RN (Release Notes) these will include a list of the bugs fixed in the version and a list of the bugs still open at current according to bug severity's criteria.

It is vital to understand QA is not releasing the version but rather giving a status report as to its quality, the decision whether to release or not is at the hands of the R&D manager and the Operational Manager according to external constraints.