Quality Assurance Plan

Software quality assurance used to be thought of exclusively as testing, but on effective projects it now encompasses testing, techical reviewing, and project planning -- all oriented toward early, economical detection and correction of defects.

This document contains a couple of Quality Assurance methods that should be followed throw the hole project. This to reduce the defects, and never-ending debugging in the end of the project. and raise the quality so we can release the software whithout being ashamed.

Revision Chart

Version Primary Author(s) Description of Version Date Completed
Draft Daniel Initial draft created for distribution and review comments 08/13/99
Final Daniel First complete draft, which is placed under change control 08/16/99
New Layout Daniel New project homepage 07/26/99

Defect tracking

Good defect information helps determine how far the project is from release, what its quality is, and where the greatest potential for improved efficency in the development process lies.

When a programmer discovers a design defect at implementation time, that defect should be tracked because the design has been baselined. If the same coder discovers a coding error in new code that has not yet been baselined, that defect shouldn't be tracked. But if the coder discovers the same defect after the code has been reviewd and baselined, that defect should be tracked.

Unit testing

Unit testings is informal testing of source code by the developer who wrote it.

Source-code tracing

Source-code tracing is stepping through source code line by line in an interactive debugger. This is done by the developer who made the code

Techical review

Techical reviews are reviews by developers of work their peers have completed.This should be done on all writing documents, requirements spec just as well as source code.

If it's only one person in the project, he/she has to finish his/her work as much as he/she would have done if it was someone else who should do the review. Then take a break, go for a walk, maybe work with someting else, or in the best case wait a couple of days. Then do the review on the document, and try to be realy objective. And forget that you have to fix the stuff later. Just find the defects. And then give the defects list back to your self. And don't forget to make a review report, it doesn't have to be complicated, but it has to be there to remind you about that you have done the review. And so it will remind you to do the review again on another document..

Integration testing

Integration testing is exercising newly developed code in combination with other code that has already been intergrated. This is performed by the developer who developed the new code.

System testing

System testing is execution of software for the purpose of finding defects. This is performed by an independent test group.

The system testing should start during Stage 1.