<enter sponsor dept/bureau name>
<enter project code & name>
Project Quality Assurance Plan
Prepared by:
Project #:
Submitted to:
Date submitted
Document version:
V0.1
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
Document Instructions
<This document template contains directions for use or sample entries. These directions are enclosed in brackets (<
>) and are italicized. They are included to help you fill out the form. As you complete the form, delete these
instructions.
Please follow this document naming convention to facilitate document search and retrieval:
<project code (if appropriate)> <project name (abbreviated)> <document name (abbreviated)>
<version (if appropriate)>
All documents should be posted to the appropriate project folder in SharePoint. >
Document History
<The document history is a log of changes that are made to the document, who made the changes, and when. For
example, the initial creation of the document may contain the following: Version 0.1, Date 1/1/2004, Author Charlie
Brown, Status Initial creation. Subsequent updates to the document will be Version 0.2, 0.3, etc. The first published
version of the document should be Version 1.0.>
Version
0.1
1.0
Date
Author
Mm/dd/yy
Mm/dd/yy
Status
Revision
Descriptions
Initial Draft
First Published
Approvals
<In lieu of this Approval section, which requires multiple signatures on one document, you may elect to use the
Approval Memo template. Distribute both the Project Quality Assurance Plan and the Approval Memo, requesting
that only the memo be printed, signed and returned to indicate approval.>
Your signature below indicates that this document meets its objectives and is acceptable.
Signature
Name
Title
Date
Signature
Name
Title
Date
Signature
Name
Title
Date
Signature
Name
Title
Date
<enter project
code & name>
Page 1 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter project
code & name>
Page 2 of 18
Project QA Plan
<enter sponsor dept or bureau name>
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
Table of Contents
1
PURPOSE OF THIS DOCUMENT ............................................................................ 4
2
ACRONYMS.............................................................................................................. 4
3
EXECUTIVE SUMMARY ........................................................................................... 5
4
INTRODUCTION ....................................................................................................... 6
4.1
4.2
4.3
5
QUALITY PLANNING ............................................................................................... 6
5.1
5.2
5.2.1
5.2.2
5.3
5.4
6
DEFINITION ....................................................................................................... 6
QUALITY STANDARDS ........................................................................................ 6
QUALITY TOOLS ................................................................................................ 6
INTRODUCTION .................................................................................................. 6
QUALITY MANAGEMENT/ASSURANCE PLAN.......................................................... 6
Product Quality ....................................................................................... 7
Quality of Service ................................................................................... 7
QUALITY METRICS ............................................................................................. 8
QUALITY CHECKLISTS ........................................................................................ 8
QUALITY ASSURANCE ........................................................................................... 9
6.1
6.2
6.3
6.4
INTRODUCTION .................................................................................................. 9
QUALITY ASSURANCE PROCESS ......................................................................... 9
QA & QC ACTIVITIES....................................................................................... 11
NONCONFORMANCE REPORTING ...................................................................... 11
7
QUALITY CONTROL .............................................................................................. 11
8
QA AND QC ROLES AND RESPONSIBILITIES .................................................... 12
9
ADDENDUM............................................................................................................ 12
9.1
9.2
10
STRUCTURED W ALKTHROUGH CHECKLIST ......................................................... 12
PROJECT COMPLETENESS AND CORRECTNESS CRITERIA ................................... 16
GLOSSARY OF TERMS ......................................................................................... 17
<enter project
code & name>
Page 3 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
1 Purpose of This Document
Quality Assurance is the managerial process that determines the organization,
design, objectives, and resources necessary to provide adequate confidence that a
product or service will satisfy the quality requirements. The use of this plan will help
assure that software development, evaluation, and acceptance standards are
developed, documented, and followed by the project team.
2 Acronyms
<Provide all acronyms that may be used within this document.>
Table: Acronyms Used in This Document
Acronym
PMM
<enter project
code & name>
Definition
Project Management Methodology (example)
Page 4 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
3 Executive Summary
<In this section, provide a brief one-page summary describing the purpose, methods, issues, and
results of the Quality Assurance Plan. This section should be completed last and should capture the
key points described in the detailed section of this document.>
[Enter the Executive Summary text here]
<enter project
code & name>
Page 5 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
4 Introduction
4.1
Definition
Quality management refers to the strategies used to control the quality of products
and services that are delivered during project execution. The goals of quality
management are to identify those quality standards that are relevant to the project,
identify the strategies for satisfying those standards, and communicate them in
order to promote their understanding and use. Specific processes are quality
planning, quality assurance, and quality control.
4.2
Quality Standards
<Determine whether the project will follow any quality standards that DOH has previously defined
and list those standards. You may also reference a published standards document instead of
retyping the standards on this section.>
[Enter text here.]
4.3
Quality Tools
<List any quality-related tools that this project will utilize.>
[Enter text here.]
5 Quality Planning
5.1
Introduction
Quality planning produces three outputs: Quality Management/Assurance Plan,
quality metrics, and quality checklists.
5.2
Quality Management/Assurance Plan
The purpose of quality management is to identify which quality standards are
relevant to the project and to determine how to satisfy them. The overall project
plan should account for quality by having it planned in, not inspected in. The
project team performs this function of planning. The Department of Health’s PMO
combines the Quality Management Plan and Quality Assurance Plan. Quality
<enter project
code & name>
Page 6 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
management strategies involve product quality and quality of services, as
discussed below.
5.2.1 Product Quality
Peer Reviews
The goal of the Peer Review process is to control the degree to which project team
members have followed the various applicable coding standards during
development. Peer Reviews are conducted for all code modules that have been
newly built or modified in response to a requirement.
Structured Walkthroughs
The goal of conducting Structured Walkthroughs is to raise and discuss issues
surrounding development in response to the most complex and risk-laden
requirements, and to bring the expertise of the entire development team to bear in
resolving those issues.
Requirements Traceability
The requirements that are defined during the Planning Phase are subject to
change throughout the subsequent project phases. Requirements Traceability
provides a means of verifying that the product conforms to scope throughout each
of the project phases. This is achieved by documenting the relationship between
requirements, design elements, code modules, and system test scripts.
Product Testing
The goal of Product Testing is to validate that the product behaves as expected
prior to implementation. The testing approaches are: Unit Testing, System
Testing, Regression Testing, User Acceptance Testing, and Load/Stress Testing.
Deployment Approvals
The goal of Deployment Approvals is to provide the owner of the system with
control over all changes to the system in the production environment.
5.2.2 Quality of Service
Lessons Learned
The goal of the Lessons Learned process is to retroactively review each project
phase after it has been completed and gather feedback from project team
members regarding how well the services delivered during that phase have met
the objectives of the phase.
<enter project
code & name>
Page 7 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
Internal Peer Reviews
The goal of the Internal Peer Review is to gather feedback from team members
regarding a proposed project artifact and to incorporate that feedback prior to
publishing the artifact for use on the project.
External Stakeholder Reviews
The goal of the External Stakeholder Reviews is to gather feedback from the
project stakeholders and team members regarding a proposed project deliverable,
and to incorporate that feedback prior to the completion of the deliverable.
Management Reporting
The goal of Management Reporting is to monitor the results of specific services
delivered on the project, communicate those results among the project team, and
identify any unsatisfactory performance that may require action by a member of
the project team.
5.3
Quality Metrics
Quality metrics are units of measurement used to assess, calculate, or determine
quality assurance and control. <Describe below the metrics used for this project.>
[Enter text here.]
5.4
Quality Checklists
Quality checklists are structured tools used to verify that all steps in a process
have been performed. They ensure consistency in frequently performed tasks.
This project has developed the following checklists:

Project Acceptance Criteria contained in the Project Charter. This checklist
includes measurable statements that define when the project is complete.

Project Completion Activities contained in each of the Closeout Phase
Checklists. These activities are lists of all the tasks that must be completed
for each phase.

Structured Walkthrough Checklist contained in the appendices of this
document. This checklist provides guidance on conducting a structured
walkthrough.
<enter project
code & name>
Page 8 of 18
Project QA Plan
Commonwealth of PA-Department of Health

<enter sponsor dept or bureau name>
Project Completeness and Correctness Criteria also contained in the
appendices of this document. This is a list of tasks which help to develop
project acceptance criteria.
<Describe below any checklists specifically developed for this project. >
[Enter text here.]
6 Quality Assurance
6.1
Introduction
Quality assurance is a consistent and structured process for measuring and
continuously improving the quality of a project. It is the activity of making sure “the
right things get done” rather than “things get done right.” The latter phrase defines
quality control.
6.2
Quality Assurance Process
The first step in the QA process is to determine the type of QA review and strategy
to use. <If the guidelines below do not contain the appropriate type or strategy, revise them to
suit your needs.>
Table: Quality Assurance Review Types
Type
Plan Review
Organization Review
Methods or Technical
Review
<enter project
code & name>
Description
Compares the plan
against the customer
requirements that it
must satisfy to ensure
that the plan includes
appropriate items.
Evaluates staffing,
training, tools, and
facilities to make sure
they meet customer
requirements.
Evaluates the
methodologies and
procedures to ensure
they are appropriate for
the project.
Page 9 of 18
Project QA Plan
Objective
To make sure the plan
will produce products
that conform to
requirements.
To certify that the
organization is able to
address the needs and
requirements of the
project.
To certify that the
methodology and
procedures will produce
products conforming to
customer requirements
or to identify future
modifications to the
Examples
 Project plan review
 Unit test plans review
 Non-program
component test plan
review
 Design documents
 <vendor> project
team review
 Customer project
team review
 System life cycle
review
 Project metrics review
Commonwealth of PA-Department of Health
Type
Description
<enter sponsor dept or bureau name>
Objective
methodology and
procedures.
Examples
Table Quality Assurance Strategy Reviews
Strategy
Self-check or Desk-Check
Peer Reviews
Informal Walkthroughs
Formal Walkthroughs
Audits
Description
An individual’s review of their own work against requirements to evaluate
conformance.
A peer’s review of work against requirements to evaluate conformance.
A critique of system construction or documentation by selected people at
any stage in the project. No formal records or meetings are necessary for
the walkthroughs.
A group review of a document or product at or near the completion of
each stage of the project.
An independent inspection, which includes examining requirements,
products, and control procedures, conducted by someone that is not
associated with the project team. A QA project team member could also
perform this audit.
<Below is a sample matrix listing the type of strategies used for various QA reviews. They should
be revised to suit the needs of your project.>
Table: QA Reviews & Strategy Matrix
Review Type
Plan Review
Project plan
Unit test plans
Non-program component
test plan
Design documents
Organization Review
<vendor> project team
review
Customer project team
review
Methods/Techniques Review
Programming standards
Project metrics
<enter project
code & name>
Page 10 of 18
Strategy Used









Formal walkthroughs
Audit
Self-check
Peer reviews
Self-check
Peer reviews
Self-check
Peer reviews
Formal walkthroughs
Frequency
Twice a month
As needed
As needed
As needed
 Formal walkthroughs
As needed
 Formal walkthroughs
As needed
 Informal walkthroughs
 Audit
As needed
As needed
Project QA Plan
Criteria for Pass/Fail
Commonwealth of PA-Department of Health
6.3
<enter sponsor dept or bureau name>
QA & QC Activities
<List the major quality assurance activities that this project will perform. Areas to consider for QA/QC
focus include:










Project status reporting
Technical reviews
Walkthroughs
Testing processes
Configuration & change control procedures
Project documentation reviews
Audits
Business requirements verification
Continuous improvement processes
Other quality processes
After quality assurance activities are identified and approved, they should be added to the project
schedule. >
This project has included the following quality assurance activities in the project work
plan:
Table: Quality Assurance Activities
Activity
ID
1
2
3
6.4
Nonconformance Reporting
A nonconformance is defined as any deviation of a product or process from
applicable requirements, standards, or procedures. These deviations can be
inferred from analyzing the Test Results Log Table. Nonconformance items should
be tracked on the Nonconformance Tracking Log --- available in the PMO template
library. The purpose of this report is to record, assign priorities, and track corrective
action for any discrepancies. The need for nonconformance and corrective action
arises early in the software life cycle, as soon as the first documents and other
products are developed.
7 Quality Control
<enter project
code & name>
Page 11 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
Quality control involves monitoring of specific project results to determine
whether they comply with relevant quality standards and identification of ways to
eliminate causes of unsatisfactory performance. This should be done throughout
the project. Tools and techniques used for Quality Control include cause and
effect diagrams, control charts, flowcharting, histograms, Pareto diagrams,
statistical sampling, and defect repair reviews.
8 QA and QC Roles and Responsibilities
The quality planning process also includes identifying the roles and
responsibilities of the project team members. The table below defines these
roles and responsibilities.
Table: QA & QC Roles & Responsibilities
Role
Quality Assurance Responsibilities
Project Manager
Project Quality Reviewer(s)
Project Sponsor
Protect Team Members
<Provide other roles & responsibilities
as needed.>
9 Addendum
<In this section add any additional information relevant to this document’s subject matter. >
9.1
Structured Walkthrough Checklist
<A structured walkthrough is an organized procedure for a group of peers to review and discuss
the technical aspects of software development and maintenance work products. The major
objectives in a structured walkthrough are to find errors and to improve the quality of the product.
Errors typically occur as omissions or contradictions, flaws in logic, or inconsistencies in the work
product style (e.g., poorly stated requirements and inefficient code). Structured walkthroughs
should not be used to discuss solutions for the errors that are found. The basic purpose of a
walkthrough is error detection, not error correction. When the walkthrough is finished, the author of
the work product is responsible for taking the necessary actions to correct the errors. >
Prior to the structured walkthrough session:
<enter project
code & name>
Page 12 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
<Use the list below as a guideline for preparation for structured walkthrough sessions. Revise as
needed for the specific project. Both the project team and the customer should agree on the
preparation steps. >
Where possible, access to the deliverable to be reviewed will be provided at least
three days prior to the walkthrough session. Participants will be requested to
review the deliverable and note any errors or defects in the product.
Appropriate support materials (such as flow charts) will be prepared to assist
reviewers with their understanding of the entire work product and how the segment
being reviewed fits into the entire product.
Reviewers will be asked to insert comments and questions directly on the review
materials. Reviewers will also be asked to note directly on the review materials
any non-technical errors found during the review, such as spelling or typographical
mistakes. While these errors are not discussed during the walkthrough, they
should be provided to the author at the conclusion of the walkthrough.
Walkthrough sessions will not exceed 2 hours in duration. If more time is
necessary, the work product segment will be divided into smaller portions and
each portion reviewed separately.
At the structured walkthrough session:
<Use the list below as a guideline for structured walkthrough sessions. Revise as needed for the
specific project. Both the project team and the customer should agree on the steps. >
Walkthrough sessions will begin with a brief overview of the work product.
The overview will be followed with a review of outstanding issues from previous
walkthrough(s).
Discussion will be limited to the identification of errors. The discussion of solutions
is not part of the walkthrough process. The author's participation will be limited to
observation and answering questions.
At the conclusion of the session, reviewers will decide the status of the work
product as follows:
A - Accept product as is
B - Revise--no further walkthroughs for this product
C - Revise and schedule another walkthrough
A majority opinion decides the action. If a majority opinion or consensus cannot be
<enter project
code & name>
Page 13 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
reached, the project manager and lead customer representative in the session will
make the decision.
If another walkthrough is necessary, the entire structured walkthrough process will
be repeated.
After the structured walkthrough session:
<Use the list below as a guideline for actions to follow a structured walkthrough session. Revise as
needed for the specific project. Both the project team and the customer should agree on these
actions. >
A Structured Walkthrough Management Summary Report will be completed. The
report will include the following information:
o Description of the work product reviewed.
o Description of findings. In addition to findings, include significant problems
that would cause schedule slippage or project cost increase.
o Date, time, and duration of the walkthrough.
o List of attendees.
o Status decision (i.e., accept as is, revise--no further walkthrough, or revise
and schedule another walkthrough) and any other follow-up activities.
<enter project
code & name>
Page 14 of 18
Project QA Plan
Commonwealth of PA-Department of Health
<enter sponsor dept or bureau name>
Structured Walkthrough
Management Summary Report
Project Name:
Module and/or Release Number:
Walkthrough Date:
Work Product (check one)
___ Strategy Study
___ Prototype
___ CoP Budget
___ Functional Specification
___ Procurement Plan
___ System Specification
___ Benefit / Cost Analysis
___ System Design
___ Project Charter
___ Data Dictionary
___ MS Project Work Plan
___ Program and Interface Standards
___ Risk Management Plan
___ Logical Model
___ Communication Plan
___ Physical Model
___ Business Requirements Document ___ Installation Plan
___ System Test Plan
___ Source Code (Module xyz)
___ Acceptance Test Plan
___ Disaster Recovery Plan
___ User Guide
___ Conversion Plan
___ Training Materials
___ Maintenance Plan
Description of Product Reviewed:
Reviewers:
Summary of Findings: (Include significant problems that would cause schedule
slippage or project cost increase)
Decision _______:
A = Accept product as is
B = Revise--no further walkthrough for this product
C = Revise and schedule another walkthrough
Circle or enter the appropriate letter:
<enter project
code & name>
Page 15 of 18
Project QA Plan
Commonwealth of PA-Department of Health
9.2
<enter sponsor dept or bureau name>
Project Completeness and Correctness Criteria
<The Completeness and Correctness Criteria section allows you to work with the customer up-front
to define what it means for a deliverable to be considered complete and correct. Then, when you
meet those terms, you would expect that the customer would indeed be happy. If you define the
criteria and expectations up front, you will be much better able to meet the customer’s expectations.
In other words, there should be no surprises.
The Completeness and Correctness Criteria vary depending on the actual deliverable being
produced. The templates give some examples of areas to consider, but each team will need to fill in
the details based on their project. There should be one section in the table for every major
deliverable that needs to be approved and one section that defines the acceptance criteria for the
entire solution.
The form contains a column for each acceptance criteria, a column for the expectations, and a
column for the actual results. Each core deliverable on the project should be listed along with the
agreed to completeness and correction criteria. When the deliverable meets the stated criteria, the
customer would sign off on the last page, signifying that they accept the deliverable as is.
This table contains examples of completeness and correctness criteria. Remove the examples and
replace with your own criteria as appropriate.>
Table: Project Completeness & Correctness Criteria
Criteria
TARGET
Examples for an IT Application
Major Features and Functions
in Place
Response Time
Well Documented
Secure
Minimal Defects
Overall Appearance
Accurate
Ease of Use
<enter project
code & name>
Page 16 of 18
All high-priority requirements are
met. At least 80% of the mediumpriority requirements are met.
The users must not have to wait for
normal response. Average
response time less than one
second, with peak times not more
than five seconds.
User documentation created and
accepted. System documented
within each program.
All security requirements met.
No more than five minor errors
during user acceptance tests. No
major errors during user
acceptance test.
At least a four out of five rating from
the system test/usability test.
All reports and online screens are
consistent and balance.
At least a four out of five rating from
the system test/usability test.
Project QA Plan
Actual
Commonwealth of PA-Department of Health
Criteria
<enter sponsor dept or bureau name>
TARGET
Must be up for a two-week trial run
before going live. The system can
be down for no more than 30
minutes during that timeframe.
Available
Examples for Project Document
Table of Contents
All Major Sections
Complete TOC must exist.
All major sections must exist,
consistent with the standard
document template.
Run spell check and syntax check.
No Grammar or Spelling
Errors
Easy to Read
Conclusion Supported by the
Facts
Attachment for Financial
Details
Attachment for Work plan
Details
Subjective, based on reader verbal
feedback.
Subjective, based on reader verbal
feedback.
The financial details are included in
a separate attachment.
The work plan is included as a
separate attachment.
10 Glossary of Terms
<Include all terms that may not be familiar to the reader.>
Term
<enter project
code & name>
Table: Glossary of Terms used in This Document
Definition
Page 17 of 18
Project QA Plan
Actual