X Project Quality Assurance Plan

X project Quality Assurance Plan Version 1.
2004, WWW.BUGHUNTRESS.COM
BUG HUNTRESS
Project: Document: File: X project Quality Assurance Plan IM_for_Palm_Quality_Assurance_Plan_1.doc Version: Date: 1.0 16/July/02
Revision History
Date 19/07/02 Version 1.0 Initial edition Description Author Alexandre Stelmakh
Example
Page 2 of 13
BUG HUNTRESS
Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview Quality Objectives Management 3.1 Organization 3.2 Tasks and Responsibilities Documentation Standards and Guidelines Metrics 6.1 The following primitive metrics stand for: Review and Audit Plan Tools, Techniques, and Methodologies Configuration Management 4 4 4 4 5 5 6 6 6 7 8 8 9 9 10 12 12 13 13 13
2. 3.
4. 5. 6.
7. 8. 9.
10. Supplier Controls 11. Quality Records 12. Risk Management
Example
Page 3 of 13
BUG HUNTRESS
Quality Assurance Plan
1.
Introduction
The introduction of Quality Assurance Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Quality Assurance Plan.
1.1
Purpose
The purpose of this document is to provide a single point of reference on the topic of quality for X project. This document does not contain details review and evaluation techniques, criteria, metrics, etc.
1.2
Scope
Quality Assurance Plan applies to X project developed by our company. This document describes issues related to quality assurance. Target audience of this document is as follows: Customer representatives; Quality Assurance group; Project Manager.
1.3
Definitions, Acronyms, and Abbreviations

VSS - Visual SourceSafe RUP - Rational Unified Process SDP - Software Development Plan SRS - Software Requirements Specification CCM - Configuration and Change Control Management SLOC - Source Lines of Code SCO - Software Change Orders
Example
Page 4 of 13
BUG HUNTRESS
1.4
References
Software Development Plan (SDP) Software Requirements Specification (SRS) Acceptance Test Description Test Plan Architecture Reference Document Status Assessment (optional) Test Evaluation Summary Defect Tracking Guidelines Risk List
1.5
Overview
This document describes organization of development process from the point of achieving the highest software quality. The section Quality Objectives describes product quality requirements. The section Management describes the organizational structure of quality assurance department, responsibilities and communication between team members in order to facilitate quality assurance. The section Documentation gives the list of documents which are designed to check the products conformity to quality standards. The section Standards and Guidelines describes Standards and Guidelines which will be used in product development process. The section Metrics defines the metrics that will be measured at certain control points during product development and that will allow to control the development process. The section Review and Audit Plan describes in detail schedule, resources engaged, methods and processes that will be used for project Review and Audit. The section Evaluation and Test describes product evaluation plan, and covers the techniques, criteria, metrics, and procedures of evaluation, which include walkthroughs, inspections, and reviews. The section Problem Resolution and Corrective Action describes the principles of reporting, analysis, and problem solving during the project.
Example
Page 5 of 13
BUG HUNTRESS
The section Tools, Techniques, and Methodologies describes Tools, Techniques, and Methodologies used in the project. The section Configuration Management defines all Configuration and Change Control Management (CCM) activities that need to be performed on the course of project and product lifecycle. It provides the details on the schedule of activities, responsibilities assigned, and resources required, including staff, tools, and computers. The section Supplier Controls gives some background on accounting information that will be given to the client during the project. The section Quality Records describes the process of quality issues tracking. The section Risk Management and Risk Management Plan gives the information on how to manage risks associated with the project. This section defines risk management tasks that will be carried out, describes the responsibilities assigned and all additional resources required for the effective risk management.
2.
Quality Objectives
The product must comply with all of the requirements described in Software Requirements Specification (SRS). Products conformity to Software Requirements Specification (SRS) will be checked through passing the acceptance tests (see Acceptance Test Description). Upon client's verification that all of the tests have been satisfactory passed, the product is considered to be of satisfactory quality. It means that product complies with all clients' requirements and is accepted by client.
3.
3.1
Management
Organization
Role Responsibility Allocates resources, defines priorities, coordinates communication with customers and users, generally is responsible for keeping the team's focus on main goal, tries to keep the project team focused on the right goal. He also establishes a set of practices that ensures integrity and quality of project artifacts. Defines system requirements, leads and coordinates use-case modeling. Outlines the system's functionality.
Project Manager
System analyst
Example
Page 6 of 13
BUG HUNTRESS
Software architect
Leads and coordinates technical activities throughout the project. Establishes the overall structure of product architecture: decomposition of the overall structure, elements' grouping, and interfaces between these major groupings. Responsible for evaluation of project planning and project assessment at major control points over the project course. Responsible for developing and testing components, in accordance with the projects adopted standards, for integration into larger subsystems. When test components, such as drivers or stubs, must be created to support testing, the implementer is also responsible for developing and testing the test components and corresponding subsystems. Responsible for planning, design, implementation, and evaluation of the tests, including: Developing the test plan and test model Implementing the test procedures Evaluating test coverage, test results, and test effectiveness Generating the test evaluation summary
Project technical assistant Developer
Test Designer
Tester
The Tester is responsible for test execution, including test set-up and test run, evaluation of test run and error recovery, defect logging and test results recording.
3.2
Tasks and Responsibilities

To assure the high quality of product the following actions must be done: Project Review and Audit according to Review and Audit Plan. Responsibilities are described in corresponding section of this document. Software Testing according to Test Plan. Responsibilities are described in corresponding section of this document. Acceptance testing according to Acceptance Test Description. Responsibilities are described in corresponding section of this document.
Example
Page 7 of 13
BUG HUNTRESS
4.
Documentation
Software Development Plan (SDP) Software Development Plan is a comprehensive, complete document, which embraces all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is to be followed throughout the project. Test Plan Test Plan contains information about the purpose and goals of testing within the project. Additionally, Test Plan identifies the strategies to be used for test execution. It also identifies the resources needed. Software Requirements Specification (SRS) Software Requirements Specification (SRS) comprises complete software requirements for the whole system and its parts. When using use-case modeling, the SRS describes use cases of the model and applicable Supplementary Specifications. Acceptance Test Description Acceptance Test Description contains Test cases. After they are passed software product is considered to be the one that meets clients requirements. Architecture Reference Document Reference Architecture is, in essence, a predefined architectural pattern, or set of patterns, partially or fully initiated, designed and approved for use in particular business and technical environment. Often, these patterns are adopted from previous projects. Status Assessment (optional) One of the development process' objectives is to ensure that expectations of all parties are consistent and synchronized. The periodic status assessment provides a mechanism for managing everyone's expectations throughout the project lifecycle Test Evaluation Summary Test Evaluation Summary organizes and presents the test results and key units of measurement for test review. In addition, Test Evaluation Summary contains evaluation by testers and test designers, of this information and recommendations for future efforts are given. Risk List A sorted list of known, open risks to the project, sorted in decreasing order of importance, which are associated with specific mitigation or contingency actions.
5.
Standards and Guidelines

Product development is performed on the basis of the following standards and guidelines: Palm Handheld Design: Basic User Interface Design http://oasis.palm.com/dev/kb/present/1110.cfm It contains the description of of PalmTM Handheld Designprinciples, Palm UI Elements and the basics of Software Application Design for Palm OSTM.
Example
Page 8 of 13
BUG HUNTRESS
Software should comply with the requirement of Palm Powered Compatible Test Kit for the Palm Powered Compatible Solutions Logo Program. http://www.qpqa.com/palm/os-index.html Palm Powered Compatible Solution logo (formerly Designed for Palm Computing Platform Platinum logo) provides assurance that Palm OS product meets compatibility, quality and usability standards set by Palm, Inc.
6.
Metrics
To provide control over the development process and quality assurance the following metrics are used: Metric Progress Purpose Iteration planning Completeness Iteration planning Rework indicator Release criterion Sample measures/perspectives SLOC
Quality
Number of errors Defect discovery rate Defect density Test hours/failure and type of failure
Maturity
Test coverage/adequacy Robustness for use
6.1
The following primitive metrics stand for:

SLOCt = Total size of the code, source lines of code SLOCc = Current baseline SCO0 = number of type 0 SCO, Software Change Orders SCO1 = number of type 1 SCO, Software Change Orders
Total SLOC SLOC under configuration control Critical defects Normal defects
Example
Page 9 of 13
BUG HUNTRESS
7.
Review and Audit Plan

Review and Audit Tasks Requirements Review (maps to traditional Software Specification Review - SSR) (concerned mainly with the Software Requirements Specification) is performed at about 1/3 of the elaboration phase. Architecture Review (maps to the traditional Preliminary Design Review - PDR (concerned mainly with the Architecture Reference Document ) is performed at the end of the elaboration phase. Code Review ( source code verification). Organization and Responsibilities Requirements Review Project technical assistant or Review intendant is responsible for the initial creation of a review report. He analyzes Software Requirement Specification and presents the results of his work to development team. He is also responsible for revision history keeping. Software architect and Software analyst are responsible for updating and making corrections of Requirements review. They are also responsible for the revision history keeping. Architecture Review Project technical assistant or Review intendant is responsible for the creation of Architecture review, which is devoted to software Architecture analysis He is also responsible for the revision history keeping. Software architect and Software analyst are responsible for updating and making corrections of Requirements review. They are also responsible for the revision history keeping. Code Review Developer or Review intendant is responsible for creation of the initial review as a text-file kept in the Source Control System. Code Review is a result of source code proofreading and checking its compliance with Code Requirements.
Example
Page 10 of 13
BUG HUNTRESS
Other Developers or reviewers are also responsible for adding their comments to Code Review. Code Review intendant is responsible for code correction in accordance with the final Code Review version. Problem Resolution and Corrective Action Requirements Review Project technical assistant or Review intendant composes the initial review version, where he analyzes Software Requirement Specification. This document must be revised by Software architect and Software analyst, who would add some points or correct Requirements review, using track changes mode. In case of disagreement between the reviewers and the owner, a special meeting is assigned, where all disputes are resolved and agreement upon the final version of the document is reached. Architecture Review Project technical assistant or Review intendant composes the initial review version, where he revises Architecture Reference Document. This review is also proofread by Software architect and Software analyst, who make necessary corrections to Architecture Review, using track changes mode. In case of disagreement between the reviewers and the owner, a special meeting is assigned, where the all points of dispute are covered and agreement upon the final version of the document is reached. Code Review Developer or Review intendant makes the initial review version as a text-file kept in the Source Control System (a result of code proofreading). This document must be revised by other Developers or reviewers. In case of disagreement between the reviewers and the owner, a special meeting is assigned, where all disputes are resolved and agreement upon the final version of the document is reached. On the basis of this document the source code must be modified by the Code owner and checked by the Review intendant for its compliance with the final Code Review version.
Example
Page 11 of 13
BUG HUNTRESS
8.
Tools, Techniques, and Methodologies

Tools Mantis bug tracker is used as a bug tracker for this project. Techniques Black Box Testing Black-box tools deal only with use cases or functional description of the test target compared with white-box tools, which are based on the knowledge on how the test target processes the request. Black-box tools rely upon the input and output conditions to evaluate the test. White Box Tests White-box tools rely upon the knowledge of code, design model(s), or other source material to implement and execute the tests. Ad Hoc Testing Ad hoc testing involves the use of unstructured or previously unplanned activities. This testing method provides the test methodology with a degree of variability. Methodology RUP methodology is used. Rational Unified Process (RUP) is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within predictable schedule and budget.
9.
Configuration Management
During the project implementation Source Control System is used. All project artifacts like documentation, source code, etc. are kept in the single Source Control System. The daily backup of the data from Source Control System is done. The person responsible for daily data backup is the appointed Implementer. VSS v.6.0c is used as a Source control system.
Example
Page 12 of 13
BUG HUNTRESS
10.
Supplier Controls
During the project implementation the following reports are given: Review and audit documents after certain reviews and audits are done. Test Evaluation Summary after the testing stage of a systems part or the whole system is over. Acceptance Testing Description after it s created. Status Assessment optional. It is done upon client's request. Risk List during the whole project lifecycle.
11.
Quality Records
All defects found during the testing phase are processed according to Defect Tracking Guidelines (internal document). During the project implementation Mantis bug tracker is used as a defect tracking system.
12.
Risk Management
Risk Management practice is the following. Risk List is created and supported during the whole project life cycle. The person responsible for creation and support of the Risk List is Project Manager. All team members take part in creation and maintenance of the Risk List, making necessary marks in its revision history.
Example
Page 13 of 13

X Project Quality Assurance Plan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

X Project Quality Assurance Plan

Uploaded by

Copyright:

Available Formats

X project Quality Assurance Plan Version 1.

10. Supplier Controls 11. Quality Records 12. Risk Management

Quality Assurance Plan

Definitions, Acronyms, and Abbreviations

Project technical assistant Developer

Tasks and Responsibilities

Standards and Guidelines

Test coverage/adequacy Robustness for use

The following primitive metrics stand for:

Review and Audit Plan

Tools, Techniques, and Methodologies

You might also like