"Pandora QA Plan v0 2"
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. 18.104.22.168 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. 22.214.171.124 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.