QuartzWare Logo




 

 

 

 

Subscribe To The Newsletter
"Timeless Software Solutions"
Team Planning Tracking Technical Deliverables Contact

 

Quality Assurance Plan (Checklist).

Release Checklist

QA Checklist v1.04- Word Format
QA Checklist v1.03
- Word Format
QA Checklist v1.02- Word Format
QA Checklist v1.01- Word Format

QUALITY ASSURANCE PLAN

The following activities will be engaged in to assure product quality.

Defect Tracking

Defect Tracking will be used to keep records of all open and closed defects found in the project's main build.  All members of the group are responsible for recording any defects found in the project.  This record must contain which release the defect was found, the type of defect, the priority, and severity, and a description of the defect.  We will be using Teamatic to keep track of all defects found.  The idividual who found the defect will record the defect on the Teamatic web site and discuss with the team as to who will be responsible for correcting specific defect.  The defect record will contain an I.D., description, how it was produced and who is responsible for fixing it, and all information that was recorded by the person who found the defect.  This record will also contain the date the defect was fixed and by whom. 

 

A record is keep of how many defects there are, on the Teamatic site.  This record will be tracked Before each meeting to see if there are any new defects or any changes to current defects.  We will be keeping track of the number of defects per release.  These numbers will be kept on the teamatic site, where we sections for each release.

Technical Reviews

Source-code walkthroughs will be done on all code before it is integrated into the project. This will ensure that all code uses the correct coding standard and that the algorithms are correct.  The one who wrote the code cannot do the walkthrough; it must be given to at least one other member of the group.  The code writer must supply a hard copy of any code to be reviewed.  The reviewer(s) will keep a record (a sheet of paper using a bulleted list) of the walkthrough which will include the names of the coder and the reviewer(s), the date of the review, the function that is reviewed, the modules that are used, and any errors or changes needed to be made to the code.

After the code has been reviewed a short meeting will occur where the reviewer(s) and the coder will discuss any errors and changes needed.  Any new changes or revisions to the error list after this meeting will be added to the document.

Changes will then be made to the code to correct all problems found during the review.  At that point the reviewer(s) and the coder will sign the document.  The document will be given to QA for tracking the level of compliance with the coding standard as well as the amount of rework is required for each stage release.  Compliance with this procedure is mandatory.  Any code that has not gone through this will not be allowed into the build and not counted as complete.

Metrics

Each member of the project is responsible for gathering his or her own metrics information.  This will consist of several documents. The first is a time log that will give a description of specific work done for the project and the amount of time spent rounded to the nearest 0.25 hours.  This information will be sent to the Team Manager and Quality Assurance person no later than Sunday of every week by 5:00 PM.  The QA will then compile this information and report on them in terms of individuals and total group for each week.  These metrics will also be placed on the web site and updated.  See Project Managers Status Reports for week time log.

After a coder has submitted his code into the main build a completed PSP time report will be due at the beginning of the next Team Meeting.  This will be submitted to QA for record keeping. 

Action Items will be assigned every Team Meeting.  These items will assign jobs to specific people and these items will be placed add to the action items section of the team site.  As each action item is completed they will be marked off.  All members are to complete the assigned action items by the date due.  This information will be used to help determine how on schedule the project is.

Coding Standards

See Coding Standard Document

Source Code Tracing

All code that is written for this project must be traced.  This will help ensure that the code logic has been fully checked.  This trace will be begin being very informal.   The coder will trace through their own code after they believe they are complete with the functionality.  They may walk through the code line by line following the logic by hand, or if this does not seem to be effective a trace of the code should be run using a debugger.  Either ways are acceptable at this point of the project.  This might change after the seconded release however if manual tracing proves unacceptable or if Walkthrough inspections show a lack of logic tracing being done.

Testing

See Test Plan Document

Requirements Traceability

To ensure the design contains all requirements we will use a traceability matrix.

 

01/16/01          Original Document Created, Tony Johansen

01/24/01          Teamatic's info added, and Coding Standard moved, Tony Johansen

02/01/01          Teamatic's link added, Completed Defect Tracking, Tony Johansen

02/01/01          Technical Review updated, Tony Johansen

02/01/01          Source code tracing added, Tony Johansen

02/12/01          Test Plan link added and updated defect tracking, Tony Johansen

 

 

   

 

 

| home | team | planning | tracking | technical | deliverables | contact |

Copyright (c) 2000 QuartzWare. All rights reserved.
Site created by Anthony Tomarchio of Teknokratz, Inc.