Pandora QA Plan v0 2 by HC120911093212

VIEWS: 4 PAGES: 5

									1 Quality Assurance Plan


1.1       Introduction

The primary purpose of the quality assurance plan is to describe the activities that will allow the
team to track and control product quality. These activities will detect defects within the software
products or documentation artifacts throughout the software lifecycle. The goal of these activities
is to remove defects earlier in the lifecycle.


This plan describes the activities that will be performed throughout the lifecycle of the project to
promote the quality of the software products. This plan does not describe quality assurance
activities to be performed during the maintenance phase of the software products since the studio
project ends after delivery.


The following sections will describe the defect management process and the quality assurance
activities for requirements, architecture, design, and implementation.


A defect is defined as something that causes the software to behave in a manner that is
inconsistent with the requirements.



1.2       Defect Management



1.2.1      Defect Detection

This project will use two general defect detection techniques: peer review and testing.
Documentation artifacts and source code will both be peer reviewed, but only source code will be
tested.



1.2.2      Defect Information Collection

The following information will be recorded for each defect:
          Description
          Severity
          Date discovered
          Person who discovered the defect
          Estimated time to remove defect
          Artifact that injected the defect
          Artifact that the defect was discovered in
          Artifacts impacted by the defect
          Date removed
          Person who removed the defect
          Actual time to remove defect



1.2.3      Defect Tracking

The team will track defects using the defect tracking tool Bugzilla. Defects will be prioritized
and assigned to a developer for removal. The status of the outstanding defects will be reported at
weekly team meetings. The current defect density will also be reported on a weekly basis.


The metric to measure quality is defect density. For documentation artifacts, the defect density is
the number of defects per page. For source code, the defect density is the number of defects per
1000 lines of code (KLOC). A standard definition for LOC will be followed to ensure that the
measurements are consistent for source code written by different the team members.



1.2.4      Defect Control

At regular intervals, the team will analyze the data generated by the defect tracking tool and
report metrics such as the defect density, the defect injection rate, and the defect removal rate.
The team will determine if the values are acceptable or if additional quality activities such as
inspections are necessary.



1.3       Quality Assurance Activities
1.3.1   Requirements

Informal peer reviews will be performed on the requirements documentation. Specifically,
       All of the use cases will be documented and reviewed by the team
       The customer meeting minutes will be reviewed by the team and made available to the
        customer within a week of the customer meeting
       All of the requirements will be documented in the SRS and reviewed by the team


After the SRS has been reviewed by the team, it will be submitted to the customer for approval.
The customer will review the SRS and provide comments. The team will review the comments
and include agreed upon changes. Once the team and the customer are satisfied with the SRS,
they can sign it. Any further changes to the SRS will require review and approval by both the
team and the customer.



1.3.2   Architecture

Informal peer reviews will be performed on the architectural documentation. The team expects
that the development of the architecture will be an iterative process and will require continuous
discussion and review.


After the notional architecture has been documented and reviewed by the team, an ATAM will be
performed. All of the team members and the customer will participate in the ATAM. Any
artifacts produced by the ATAM will be documented and reviewed.



1.3.3   Design

Informal peer reviews will be performed on the design documentation. Similar to the
development of the architecture, the team expects that the development of the detailed design will
be an iterative process and will require continuous discussion and review.



1.3.4   Implementation
Two defect detection techniques will be performed on the source code: peer reviews and testing.
For more detailed information regarding quality assurance activities during implementation, see
the Verification and Validation Plan.


1.3.4.1 Peer Reviews

Walkthroughs (informal peer reviews) will be performed on the source code. In the walkthrough,
the author leads the reviewer through the source code. The reviewer asks questions and makes
comments about possible errors, violations of the coding standard, or other issues. All of the
source code must have had a walkthrough performed by at least one reviewer.



1.3.4.2 Testing

There will be four levels of testing: unit testing, integration testing, system testing, and
acceptance testing.


Unit Testing


All developers will create and perform unit tests for their respective modules. Unit tests will
specify inputs and expected outputs from the module in testing. The team will perform
automated unit testing using JUnit. Performing unit tests will help detect defects before system
integration.


Integration Testing


After a module has passed unit testing, the developer will perform integration testing. During
integration testing, the developer ensures that their module works properly with respect to the rest
of the modules locally on their development machine. This will ensure that the module will
behave correctly when integrated into the software baseline.


System Testing


After all of modules have been integrated into the software baseline, the team can perform system
testing. During system testing, the developers will ensure that the baseline system operates
without bugs and that all of the customer’s requirements have been realized. The test procedures
for this process will be dictated precisely within the V&V document; however the individual
testing scripts will be built as necessary for the system in one of many test plans.


Acceptance Testing


After the software baseline has passed system testing, the system may be ready for acceptance
testing. Before the software can be presented to the customer for acceptance testing, every defect
that has not been removed must have a workaround. In acceptance testing, the team will perform
a demonstration of the most important features of the software product. The system passes
acceptance testing with the approval of the customer for delivery.

								
To top