Quality Assurance Plan

Source-Code Tracing
Source-Code Tracing is basically, stepping through source code line by line in an interactive debugger. The developer who wrote the code does the Source-Code Tracing. This will serve to reduce integration problems as well as most defects. Any major modules must go through Source-Code Tracing before they are passed on to Mike for Integration. There will be no metrics collected/recorded nor will there be any log or documentation. Compliance is tracked by whether or not the module compiles correctly and accountability is realized because who is responsible for what module is listed in our integration plan.

Defect Tracking
Defect tracking is the recording of bugs and their status in order to increase the awareness of the importance of eliminating defects early. It also helps determine how far the project is from release, what its quality is, and where the greatest potential for improved efficiency in the development process lies. In order to avoid confusion every defect found and fixed must have a report made about it. Everyone will do Defect Reports for every defect. These will be filed at www.teamatic.com. I, Apel Yahinian, will supervise as QA Lead. Defects are made up of (Before Stage 2 release) only those errors found through system testing after the code has been deemed "complete". The following fields must be filled in when a defect is found (Starting after Stage 2):

Requirements Traceability
Wesley Strickland is responsible for this activity and it basically consists of creating and maintaing a Requirements Traceability Matrix within which is listed all the requirements and all the methods associated with that requirement.

Technical Reviews
Technical Reviews are reviews by developers of work their peers have completed. These reviews are used to assure quality of the technical work products. We will suffer at the minimum, 1 Technical Review per each Staged Delivery. These sessions will consist of everyone either going over our work one at a time with the whole group presiding. Or, if this takes too long or is inefficient, we will all choose one person per session and have them review our code as we review theirs. This will begin Thursday, February 8 in lab and continue until finished. Subsequent reviews will be scheduled as needed or decided later.
Link to Software Inspection Procedure(not up yet)

Coding Standards
Everyone should follow our coding standards ALL the time. If they do not follow the coding standard they will be found out during our code reviews. By checking in the Integration Plan we can find out who was supposed to code that method/module and place responsibility accordingly.

Unit Testing
Unit testing is informal testing of source code by the developer who wrote it. The word "unit" can refer to a subroutine, a module, a class, or an even larger programming entity. Unit testing is usually performed informally but should be required for each unit before that unit is integrated with the master sources or turned over for independent review or testing. All software modules must be unit tested by their developer BEFORE they are given off to Mike to be integrated. In other words, it has to work before you submit it.
Link to Unit Testing Procedure

Integration Testing
Is exercising newly developed code in combination with other code that has already been integrated. Mike Power will cover integration but I must also be present in order to sign off on it and to ensure that everything has gone over correctly.
Link to Integration Plan

System Testing
System Testing is the execution of software for the purpose of finding defects. It will begin after Stage 1. System Testing will consist of outside people who have the minimum of knowledge in order to critique our project. It must occur once after each Staged delivery. System Testing also makes extensive use of the outside people coupled with our Tester in order to produce new testing programs with a fresh viewpoint.
Link to Test Plan

Change Control
All items involved in our project are listed under Change Control. If someone feels that something should be changed they should refer to the Work Product Change Control Summary to find out what form to refer to.
Link to Change Control Plan

PSP
The PSP forms for a unit you develop are to be submitted to the QA manager during the first class session after the unit has been submitted to the build. The QA manager gathers all the PSP forms and may publicize which have been completed (but do not publicize individual data). The QA manager submits all the PSP forms to the instructor with the Release.
Link to PSP page

Unit Developer Procedure
When someone begins coding they should immediately look to the Unit Development Procedure and the PSP to guide them.