SQA plan

Author:Miro Kresonja, SQA manager
Date:12/01/98
Version:1.2


Responsibilities:

The SQA manager has the responsibility to verify the compliance with the SQA procedures(defined later in the document), to inspect intermediate and final products, development and verification activities. The SQA group will give feedback to the management on a regular basis (at least twice a week).

SQA Procedures

Peer review procedures

  • There will be regular code walkthroughs. They will be performed at least once per each loop through the spiral model, and will be performed in a circular fashion, (i-th developer will review i+1-th developer's code). All deficiencies will be noted and used to improve the process.
  • During each code walkthrough, two categories of measurements will be taken (and deficiencies removed): relative and objective.
    Relative deficiencies are: code efficiency (how few resources are consumed), code accuracy (how close the given product comes to the given specifications).
    Objective deficiencies are: errors in formatting, non-standard variable names, lack of inline documentation, and coding standards (such as deallocation of all allocated memory).
  • A checklist will be used during code walkthroughs.
  • Note: Should the full walkthough procedure be deemed not necessary by the assembled managers, a shortened review session will be employed. In the shortened session, each programmer will go through a representative method/class with the rest of the programming team, answering and asking questions about the code. Each programmer will then fix deficiencies noted either before (critical errors) or after (non-critical errors) the release date.
    The notes of the last partial walkthough are here.

Testing procedures

  • A body of tests will be made for each version of the product. These tests will be devised in such a manner that all the requirements for that version are tested.
  • A similar body of tests will be designed for each intermediate stage of the project.
  • After a developer is finished with a module, he shall run unit tests on his module, simulating the real inputs to the module.
  • If the unit testing passes, a developer will check his module into the depository with the project manager's consent.
  • At each intermediate stage of the project, full body of tests will be run.
  • A more detailed testing description (reasons, procedure) is located here.

Reporting procedures

  • Should any deficiencies be found, in any of the areas listed under the SQA responsibilities, the SQA manager will note them, and present the compiled list at the next group meeting.


Revision history:
Version 1.0 (created) - 10/21/98
Version 1.1 (added) - 11/04/98
Version 1.2 (added) - 12/01/98