<Project Name>

Test Plan

Test Plan Template Instructions

(Please remove this section before completion of template)

The Test Plan will cover all aspects of the testing and should outline the plan to execute that testing. All testing should be identified in this document, including but not limited to, the requirements, installation verification, unit testing, integration, performance, user acceptance, security and recovery.

Be sure to maintain version control as the analysis is modified and/or edited.

All instructions within the template are italicized within the document.

Any examples are in a red font.

Any portion of the template that does not fit or pertain to your project should be documented that it was reviewed and is not relevant. See below for requirements for a project and deliverable approvals.

Be sure to unlock table of contents by selecting TOC then Ctrl-Shift-F11 to enable TOC updating in Word docx.

Project Deliverable	Requirements by Project Size
Planning/Development Phase	Large	Medium	Small	Requirements	Approvals
Test Plan (SDLC)	R	R	R	This process is critical and required for all projects, regardless of size.	The Test Plan will have two approvals. The first approval will be the plan for the testing, and the second will be the test results or completion of the testing. The Test Plan should be approved by the Sponsor, the Steering Committee and the Implementation Team, at a minimum.

Table of Contents

1.	Introduction	3

1.1.	Purpose	3

1.2.	Assumptions	3

2.	Version Control	4

3.	Testing Strategy	5

3.1.	Requirements Validation	5

3.2.	Installation Verification	6

3.3.	Testing Coordination	6

3.4.	Unit Testing	6

3.4.1.	Definition:	6

3.4.2.	Participants:	6

3.4.3.	Methodology:	6

3.5.	System Integration Testing	7

3.5.1.	Definition:	7

3.5.2.	Participants:	7

3.5.3.	Methodology:	7

3.6.	Security Testing	7

3.6.1.	Definition:	7

3.6.2.	Participants:	7

3.6.3.	Methodology:	7

3.7.	Performance and Stress Testing	7

3.7.1.	Definition:	7

3.7.2.	Participants:	7

3.7.3.	Methodology:	7

3.8.	User Acceptance Testing	8

3.8.1.	Definition:	8

3.8.2.	Participants:	8

3.8.3.	Methodology:	8

3.9.	Recovery Testing	8

4.	Resources/Roles & Responsibilities	9

5.	Requirement Guide	10

Entry Requirement	10

Exit Requirement	10

Suspension Requirement	10

Resumption Requirement	10

6.	Test Schedule	11

7.	Tools	12

8.	Control Procedures	13

8.1.	Defect Reporting	13

8.2.	Defect Reviews	13

8.3.	Change Requests	13

8.4.	Resumption Criteria	13

9.	Approvals	14

9.1.	Plan Approval	14

9.2.	Completion Approval/Acceptance	14

Introduction

Purpose

All systems need to be tested. In fact, system testing is a major part of the overall system development process that involves many people and countless hours of detailed work. Unfortunately, most testing efforts are under-planned: some software testing professionals work in the field for years without ever seeing a really comprehensive QA plan and test suite. Part of the problem is that QA efforts often begin too late in the release cycle when there is too much pressure to take shortcuts. Additionally, they may concentrate on only a subset of the system, such as the software itself, and not consider the hardware or network.

System testing is a trial of a system to ensure it performs as is expected and required. System testing is the process of validating and verifying that a software program/application/product meets the business and technical requirements that guided its design and development, so that it works as expected and can be implemented with the same characteristics.

Detail the purpose for the testing on this project.

Assumptions

This document assumes.....

Version Control

Version	Date	Person	Change
1.0	Initial Document Creation

Testing Strategy

List the tests to be performed and the expected results. The plan should consider hardware, middleware, software and infrastructure including the network.

System development projects that don't have enough test planning tend to get bogged down with defects that can put the entire project's success at risk.

Installation verification, integration, system, user acceptance, usability and accessibility are some of the types of testing that should be considered.

Outline the project strategy to perform all the necessary testing.

While using RUTGERS approved tools, and in accordance with RUTGERS policies, accessibility testing should also be conducted to ensure that applications and systems comply with section 508 of the Rehabilitation Act of 1973.

Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.*

*Source: http://www.section508.gov/index.cfm?FuseAction=content&ID=12

Requirements Validation

Designing a system test plan forces you to deeply understand the requirements. As you understand the requirements more, you will notice incompleteness, ambiguity, and inconsistency in the system. Correcting these problems early should speed up development and reduce the number of late requirements changes. Test plan can also be used for testing and troubleshooting the system and assist in actual development and user requirement confirmation by providing a document that shows what the output should be when certain actions are performed.

Document testing scenarios and expected outcomes for the requirements of the project as defined in the Requirements Analysis Process. Use the matrix developed in the Requirements Analysis:

Require-ment Number	Category	Requirement Description	Scenario Performed	Expected Outcome	Actual Outcome	Pass or Fail	Comments
R-01	Security	Password formatting correct	Set user password from default.	The format excepted should be 8-12 characters, 1 capital, 1 number and no symbols	These two fields will be completed during execution of test plan. Password accepted	Pass

Installation Verification

Document that the hardware and/or software works as ordered/spec’d out, or that existing hardware and/or software will work and is in proper condition for the system being developed.

Define how the hardware and/or software will be tested and documented.

Testing Coordination

A formal testing coordination plan must be developed for effective team deployment. Testing involves many people working together over time. For the team to be effective, their efforts must be coordinated with a written plan. Document the coordination plan.

Unit Testing

Definition:

List what your understanding of Unit Testing is for your project.

Participants:

List the individuals who will be responsible for conducting Unit Testing.

Methodology:

Describe how Unit Testing will be conducted. Determine who will write the test scripts, the sequence of events in Unit Testing, and how testing will take place. Be sure to include how sign-off and final acceptance is verified.

System Integration Testing

Definition:

List what your understanding of System and Integration Testing is for your project.

Participants:

List who will be conducting System and Integration Testing on your project

Methodology:

Describe how System & Integration testing will be conducted. List who will write the test scripts for the testing, the sequence of events in System & Integration Testing, and how testing will take place. Be sure to include how sign-off and final acceptance is verified.

Security Testing

Definition:

Develop Security tests to verify that unauthorized access to restricted data or system components is prevented. **Reference Security Requirements from the Requirements Analysis and from the Security Tool and Assessment.

Participants:

List the names of individuals/departments responsible for Security Testing.

Methodology:

Describe how security testing will be conducted. List who will write the unit test scripts, the sequence of events in Security Testing and how testing will take place? Be sure to include how sign off and final acceptance is verified.

Performance and Stress Testing

Definition:

List what your understanding of Stress Testing is for the project.

Participants:

Determine which individuals will be responsible for conducting Stress Testing on the project.

Methodology:

Describe how Performance & Stress testing will be conducted. List who will write the test scripts, the sequence of events in Performance & Stress Testing, and how testing will take place. Be sure to include how sign-off and final acceptance is verified.

User Acceptance Testing

Definition:

The purpose of acceptance testing is to confirm that the system is ready for operational use. During acceptance testing end-users (customers) of the system compare the system to its initial requirements.

Participants:

List who will be responsible for User Acceptance Testing by name and responsibility.

Methodology:

Describe how the User Acceptance testing will be conducted. Determine who will write the test scripts, the sequence of events of User Acceptance Testing, and how testing will take place? Be sure to include how sign-off and final acceptance is verified.

Recovery Testing

Recovery tests force the system to fail in various ways and verify that recovery is properly performed. It is important that all data is recovered after a system failure and no corruption of data has occurred.

Resources/Roles & Responsibilities

Specify the names and roles of those involved in the test project (for example, Mary Brown (User) compiles Test Cases for Acceptance Testing). Identify groups responsible for managing, designing, preparing, executing, and resolving the test activities, as well as related issues. Also, identify groups responsible for providing the test environment. These groups may include developers, testers, operations staff, testing services, etc.

Requirement Guide

There are many different opinions as to how the test plan should be written and organized, but having a thorough and useful test plan is the main goal. The Requirement Guide should be referenced and used for the Test planning process. There needs to be guidelines outlined for when testing should begin, stop and restart. Those requirements need to be outlined here.

An example of a testing requirement may be:

Entry Requirement

Test plan approved

Test environment stable and ready

Test cases documented and distributed

Test tools ready

Test resources available

Exit Requirement

Test case completion with Steering Committee approval

Identification of open defects with quality impact analysis

Test objectives successfully met

Suspension Requirement

Unstable testing environment

Unavailable resources

Data corruption

Resumption Requirement

Verified stable test environment

Resource availability meets testing demand

Data integrity verified

Test Schedule

Include test milestones identified in the Project Schedule, adding any additional test milestones, as needed. Specify the schedule for each testing task and milestone. For each testing resource (facilities, tools, and staff), specify its periods of use.

Tools

List the Automated and/or manual tracking tools to be used.

One common tool for the testing plan is in a grid layout, simplified example below:

Function	Item	Action	Expected Result	Actual Result	Comments
Login	Submit valid UN/PWD	Enter valid UN and PWD and submit	Successful login to application with appropriate roles	Logged in with correct roles
Login	Submit invalid UN/PWD	Enter an invalid UN and PWD and submit	Should not get logged in and should be brought to a page indicating that there was an issue with UN and/or PWD	Not logged in, but also not brought to a page indicating issue with UN and/or PWD	The page for bad logins doesn’t work or is not displaying correctly and needs to be addressed.

Control Procedures

Defect Reporting

Define how defects in testing will be reported and tracked.

Defect Reviews

Define how defects will be reviewed and discussed, i.e. meetings, tracking sheet, etc.

Change Requests

Define the change process to correct any defects in the hardware and/or software. If this information is outlined in the Change Control Process, you may reference that document.

Resumption Criteria

If testing is suspended, resumption will only occur when the problem(s) that caused the suspension have been resolved. When a critical defect is the cause of the suspension, the “FIX” must be verified by the test team before testing is resumed.

Approvals

Plan Approval

The individuals below agree that they have reviewed and approved the plan outlined in this Support Documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Completion Approval/Acceptance

The individuals below agree that the plan outlined in this Support Documentation has been executed to completion.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Project Management Office

EXAMPLE

NJDS Axium Project

Testing Plan

Rolodex and Chart Tracker

Table of Contents

1.	Version Control	2

2.	Introduction	2

2.1.	Purpose	2

2.2.	Assumptions	2

3.	Testing Strategy	2

3.1.	Electronic Testing	2

3.1.1.	Definition:	2

3.1.2.	Methodology:	2

3.1.3.	Scripts Used:	2

3.1.4.	Coordination:	2

3.2.	User Testing	2

3.2.1.	Definition:	2

3.2.2.	Methodology:	2

3.2.3.	Script Used:	2

3.2.4.	Coordination:	2

4.	Control Procedures	2

4.1.	Defect Reporting	2

4.2.	Defect Log	2

4.3.	Defect Log Reviews	2

5.	Testing Schedule	2

6.	Approvals	2

6.1.	Plan Approval	2

Version Control

Version	Date	Person	Change
1.0	7/28/2010	Dennis Wykoff	Initial Document Creation
2.0	8/13/2010	Dennis Wykoff	Removed Scheduler from Plan
2.1	8/18/2010	F. Haies	Updated Purpose & Schedule Sections

Introduction

Purpose

The Testing Plan will document the strategy for, methodology of and control for testing Axium software functionality being rolled out to limited NJ Dental School Clinics.

This Plan will define the strategy needed to successfully test the migration of ACE Patient data to Axium’s Rolodex application plus access and processing of that data in Axium applications. Testing methodologies and defect control are also an important component of this project deliverable. Roles and responsibilities are defined to document the project personnel engaged in testing.

Assumptions

This project is not a new implementation of Axium software. This software application is currently being used in Production by Oral Medicine, Orthodontics, and Special Care Treatment Center. It is not necessary to test the native functionality of the Axium software product.

Chart Tracker will be Axium module used based on a successful migration and testing of Rolodex (patient) data. This Axium module is assumed to function as required using the migrated ACE patient data. Extensive testing of chart tracking functionality in Axium will not be performed.

The existing Production computing infrastructure is currently using the Axium software for the above three departments. Extensive testing of this infrastructure will not be performed.

The new Axium users will access the software via Citrix versus the methodology currently used for existing Axium users. The rollout of Citrix’s use for the new user departments will be in place for training, testing and go live.

Successful electronic patient data conversion testing and subsequent validation is a required prerequisite to continuing into user testing. See Testing Strategy for references to Electronic and User Testing.

End users have been selected and notified they will be conducting testing for new departments coming onto Axium.

The project plan calls for user testing in the Production environment. User testing approval and defect log entry resolution are required to continue with the Production implementation.

Any user testing in a data base instance that represents the Production database is a benefit to the project.

Testing Strategy

There is an existing user population that is currently using the Axium applications in a Production environment. They are successfully processing Rolodex (patient) data. The requirement to test Axium as if it is a new software application being implemented for the first time is not required. Therefore, the testing found in a typical software product implementation such as installation verification, unit, integration, and system is not applicable in this situation. What is required is to test new users introduced to the system, a different method of accessing the applications (Citrix), synchronizing the updating of ACE Patient data with Rolodex data entered in Axium, and processing the patient converted data for the Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative departments.

Testing will be carried out in two phases. The first phase will be to convert the Patient demographic data electronically. Patient data will be extracted from ACE, transformed for use in Axium and then uploaded with existing Patient data in Axium. Controls on the movement of data between the two systems will exist as well as a validation report of patient data elements migrated. This validation report will be reviewed and approved. The first phase is basically validation testing of generating the data needed by Axium. The second phase will allow users to log into Axium and access patient data based on their access security. A manual comparison of ACE to Axium Patient data elements will be performed. This will function as the validation of successful data migration from one system to another. Lastly, testing the synchronization of Patient data between Axium and ACE will be performed.

Testing will be carried out over multiple data base instances and at different stages of the project. The electronic data conversion will be conducted in the Train data base for initial testing and for use in demonstration and training exercises. This will improve the chances of overall successful testing in the project by validating Patient data conversion in the pre go-live stages of the project. Demonstrations and end user training will serve as another testing vehicle and surface any issues with accessing Axium via Citrix and the security built for end users from the Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative departments. Manually comparing data elements in the Train data base and also after data conversion in the Production database will serve as the final test of patient data migration prior to the end users using this data.

Electronic Testing

Definition:

Electronic testing is a method of validating the migration of Patient data from ACE to Axium via a programmatic or electronic data conversion process.

Methodology:

Patient data will be programmatically extracted from ACE, transformed, and then updated in Axium. Any problems with either the NJDS or Exan scripts getting the data to convert properly will cause an entry to the Defect Log. The Defect Log entry will be a source for follow up and resolution. The Testing Coordinator will be updated on electronic testing. When the script issue has been resolved, another conversion test will be performed. When an acceptable conversion test is performed, a passing entry will be made to the Defect Log. The data conversion process ends with a computer generated validation report not printing any data inconsistencies between ACE and Axium. Electronic testing approval and defect log entry resolution are required to continue with the Production implementation.

Scripts Used:

ACE Patient data extract scripts are referenced as an entry to the Appendix in the Data Conversion Plan.

Axium Rolodex data upload scripts are property of Exan and not available for inclusion in this document.

A Patient Data Comparison report will print only differences in converted data between ACE and Axium.

Coordination:

NJDS will coordinate with Axium Support the movement and uploading of ACE Patient data to Axium.

Axium Support will coordinate with NJDS the uploading of Axium data. Axium Support will supply information necessary for error correction and reconciliation reporting for the data conversion.

NJDS will coordinate with Axium Support any data conversion script revisions needed.

Electronic Testing Roles and Responsibility-

Testing Coordinator- Walter Latham

NJDS Support –TBD

Axium Support – Brad Miller

User Testing

Definition:

User testing will consist of a manual comparison of ACE to Axium Patient data elements to verify there was a successful data migration from one system to another followed by the synchronization testing of Axium to ACE Patient data elements. The project plan calls for user testing to be conducted in the Production environment before going live.

Methodology:

NOTE: The methodology for synchronization defined below is work in progress.

Testers will view ACE Patient data and Axium Rolodex patient data and compare data elements in each system. Testers will also invoke the Axium to ACE Patient data synchronization and verify data is accurate in both systems. In addition, user testing will verify logging into Axium and role based security setups. The objective of user testing is to confirm Axium is ready for operational use by the Endodontic, Oral Surgery, Paediatric Dentistry, Periodontal, and Restorative departments. Accessing Axium via Citrix and verifying the appropriate security is in place will help verify processing in the Rolodex application has been prepared for a Production environment.

User testing personnel will have instructional scripts for use in testing. They will contain patient numbers as a reference. Testers will access Patient data in ACE or have printouts of ACE Patient data to use for comparison to the same patient in Axium’s Rolodex. Testers will log into Axium and access the subject Patient data. Testers will login under multiple access roles to validate access security by users within a department. A field to field comparison will be made. Testers will then synchronize Axium and ACE Patient data. If there is an equal comparison or equal ACE\Axium synchronized data, the instructional scripts will be identified as passing comparison. If there are any inconsistencies with the data, the instructional scripts will be identified as failed. An entry in the Defect Log will then be made for each failing instructional script as a source for follow up and resolution. When a resolution is put in place, the defect will be retested. The Testing Coordinator will be updated on testing. User testing approval and defect log entry resolution are required to continue with the Production implementation.

Script Used:

The instructional scripts developed are intended to be reusable for future Axium upgrade testing.

Sample User Testing Script Example

Test Performed by:
RC Implementation-Functional Test Scenarios	Date:
End User Test
Test No.	Action	Alt Chart No	Expected Results	Actual Results	Pass/Fail
1	Log In to AxiUm	N/A	Ability to log In	Not able to log in. could not access application	Failed
Open Rolodex to Patient ny using Alt Chart from ACE- Use pre-printed screenshotsfrom ACE	Enter Alt. Chat No.	Should be able to locate patient	Information Matched= Success	Passed
Open Patient Card	11111111	Patient retrieved should match ACE	Able to retrieve patient	Passed
Verify that demographic data matched	N/A	Should match patient information in ACE	Patient demographic information matches ACE	Passed
2	Log In to AxiUm	Enter Alt. Chat No.	Ability to log In
Open Rolodex to Patient ny using Alt Chart from ACE- Use pre-printed screenshotsfrom ACE

Coordination:

Access to the Axium Production data base by testing personnel is required.

ACE to Axium Production conversion complete.

User Testing Roles and Responsibility-

Testing Coordinator- Walter Latham

NJDS Testers – Rosemarie Vaccaro, Additional Resource – TBD

NJDS Support - TBD

Control Procedures

Defect Reporting

Electronic Testing-

NJDS and Exan script errors only will be logged in the Defect Log. Data conversion scripts revisions will be made, Defect Log updated and the electronic testing process will begin again and continue until the validation report is clear of any and all data inconsistencies caused by script issues. The Testing Coordinator will monitor electronic testing, coordinate defect resolution and provide defect status reporting.

User Testing-

Testers will make an entry to the Defect Log for each script identified as failed. When a resolution is put in place, testers will retest the defect and make an update to the entry in the Defect Log. The Testing Coordinator will monitor user testing, coordinate defect resolution, retesting and provide defect status reporting.

Defect Log

The Defect Log will be a softcopy log that’s available to all personnel involved in testing.

ID#	Test Date	Test Step	Reported By	Script or Module	Defect Description	Assigned To	Resolution	Resolu-tion Date	Retest Date	Status

Defect Log Reviews

NJDS personnel (TBD) who have been assigned to coordinate with testers will review the Defect Log and implement defect resolutions. They will test and deploy fixes and update the Defect Log. The Testers will retest the fixes deployed and update the Defect Log.

The Testing Coordinator will monitor the Defect Log during testing (see Testing Schedule).

The Testing Coordinator will provide testing status reporting and advise of successfully completed testing.

The Testing Coordinator will advise NJDS leadership of any defect that will impact the successful completion of testing by the required completion date.

NJDS leadership will work with project personnel to resolve defects that impact required testing completion date.

Testing Schedule

Testing will consist of a 4 step process: Data Conversion Test #1, inclusive of a script adjustment period, Data Conversion Test #2, Final Data Conversion Test prior to go live and User Functionality testing as described in section 3.2.3.

Data Conversion Test #1 is planned 2 weeks prior to go live

Data Conversion Test # 2 is planned week of August 16th

Final Data Conversion Test is planned for August 27th

User Functionality Test is planned for August 27th.

Approvals

Plan Approval

The individuals below agree that they have reviewed and approved the plan outlined in this documentation.

APPROVED BY:
Function Role	Name and Title	Signature	Date

Completion Approval/Acceptance

The individuals below agree that the plan outlined in this Support Documentation has been executed to completion.

APPROVED BY:
Function Role	Name and Title	Signature	Date