Document Instructions

/ <enter sponsor dept/bureau name>

Enter project name>

Test Plan

/ <enter sponsor dept/bureau name>

Document Instructions

<This document template contains directions for use or sample entries. These directions are enclosed in brackets (< >) and are italicized in blue. 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:

All documents should be posted to the appropriate project folder in SharePoint:<Enter Sharepoint site address>.

Document History

Version / Date / Author / Status / Section / Revision Description
0.1 / Initial Draft
1 / First Published

Approvals

Your signature below indicates that this document meets its objectives and is acceptable.

Signature / Signature
<Name> / <Name>
<Date> / <Date>
<Title> / <Title>
<Role> / <Role>
<enter project code & name>
Test Plan v X.X / Page 1 of 13 / Printed: 1/23/2019
/ <enter sponsor dept/bureau name>

Table of Contents

1Document Purpose

2Glossary and Acronyms

3Overview

3.1Scope

3.2Objectives

3.3Strategy

3.4Success Criteria

4Resources

4.1Staffing

4.2Hardware/Software/Other Tools

5Testing Phase Timeline

6Approach

6.1Test Planning

6.2Test Preparation

6.3Test Execution

6.4Bug Tracking

7Test & Acceptance Process

8Deliverables

9Appendix

<enter project code & name>
Test Plan v X.X / Page 1 of 13 / Printed: 1/23/2019
/ <enter sponsor dept/bureau name>

1Document Purpose

The purpose of the Test Planis to define the testing approach and process. The goal of the plan is to ensure that project requirements are met, quality is maintained, and procedures are verified.The testing procedures and methods for the development through delivery of the newly designed software are outlined. The testing processesaddress end to end functional system, regression and performance testing.User acceptance testing validates the business requirements were developed as required and function as expected by the business users.

The application development lead(s) and program lead(s) signoff on the test plan, ensuring understanding and agreement on the testing scope and approach.

Document Scope & Objectives

The Test Plan documents the strategy and procedures that will be used in the comprehensive testing of project deliverables.In addition, this document includes standards for the creation, documentation, and execution of system development and acceptance tests.

The objectives of the system process are to validate that the application meets the functional and technical design specifications as defined in the General System Design and Detailed System Design Deliverables.

2Glossary and Acronyms

Provide a general list of common terms and acronyms and any project-specific terms or acronyms that may be used within this document; remove any that do not apply. Pull agency-wide applicable acronyms from HealthHUB

Table: Terms and Acronyms

Term/Acronym / Definition
BIIT / Bureau of Informatics & Information Technology
BRD / Business Requirements Document – Details the business solution for a project including the documentation of customer needs and expectations.
DOH / Department of Health
MTM / Microsoft Test Manager – Microsoft Test Manager is used to help test the application is being built.MTM stores the test plans and results on Team Foundation Server (TFS).
OPS / Operational Support
PMO / Project Management Office
QA / Quality Assurance
RTM / Requirements Traceability Matrix – a process of documenting the links between the requirements and the work products developed to implement and verify those requirements.The RTM captures all requirements and their traceability in a single document.
SDLC / Software development lifecycle – A software development lifecycle is essentially a series of steps, or phases, that provide a model for the development and lifecycle management of an application or piece of software.
SDLC Agile Methodology / The Agile methodology model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product.The Agile methods break the product into small incremental builds.These builds are provided in iterations.Each iteration typically lasts from about one to three weeks.Every iteration involves cross functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing and acceptance testing.At the end of the iteration a working product is displayed to the customer and important stakeholders.
SDLC Waterfall Methodology / The Waterfall methodology was the first Process model to be introduced.It is also referred to as a linear-sequential life cycle model.It is very simple to understand and use.In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
TFP / Test for Production
TFS / Team Foundation Server – Team Foundation Server is a Microsoft product that provides source code management, reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, lab management, testing, and release management capabilities.It covers the entire application lifecycle.
UAT / User Acceptance Testing – This is the last phase of the software testing process.During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications.
VSTS / Visual Studio Team Services – a set of cloud-powered collaboration tools that work with your existing version of Team Foundation Server and Microsoft Test Manager.

3Overview

The overview functions as the “executive summary” of the test plan: its goals, its scope, and its schedule. This should be kept brief, as you will go into further detail in subsequent sections of the test plan.

3.1Scope

Your scope should define, in general terms, the methods that will be used in the testing process and the projected results. The scope should also include the most critical performance measures, as well as a list of what the test plan will not address, and why.

3.2Objectives

Your test plan should clearly define what you will test and why you will test it. These should always be based on industry standards.Determine what the scope of the test is.What scenarios will be tested?Determine what is out of scope for the test.What scenarios will not be tested?Common scenarios include Module/Unit Testing, Integration Testing, Systems Testing, Acceptance Testing, and Beta/Pilot Testing.

3.3Strategy

This section outlines the overall test strategy for your test plan. It will include any project strategy that impacts the testing (i.e. phased approach, pilot, etc). It will specify the rules and processes that will apply to the tests.Include information on tools to be used, what metrics will be collected and at what level, how many configurations will be tested, and whether there are any special requirements or procedures for testing.

3.4Success Criteria

<This section outlines the success criteria for your testing effort.Testing success criteria are the standards by which the test effort will be judged successful. In this section document how each objective or goal will be met. Include the acceptance criteria from the business/program areas required to obtain signoff approval for implementation.

4Resources

<This section describes all of the resources needed to complete the testing, including hardware, software, testing tools, and staff.>

4.1Staffing

<When accounting for the team members, detail the responsibilities required of each member and the training needed to execute those responsibilities.>

Staff Member(s) / Role / Responsibilities
Project Manager (PM)
(The Project Manager is responsible for overall execution in accordance with the project plan and project design.) /

Exercise a general supervision over the activities of the QA Leads and developers, and insure that testing is thorough and complete.
Escalate any non-resolved issues to the Project Sponsor.
Review problems with users when requested by QA in order to determine whether the issue is a bug or a potential enhancement.

Business Analyst (BA) is responsible for ensuring testing covers the full scope of the project requirements and deliverables /

Insure that the requirements are complete and unambiguous for development and QA, and that they conform to the user’s standards.
Review the User Acceptance test cases for traceability to requirements and functional specifications.
Verify each deliverable has been tested in accordance with the procedures in the project’s test plan.

System Analyst
(The System Analyst may be an application developer, the DBA, a documentation developer, or any other member of the development project team.) /

Develop the work product in accordance with specifications and standards.
Test that work product to confirm adherence to those specifications and standards.
Perform test activities detailed in the project’s Test Plan.
Correct any deficiencies and/or problems, whether or not they are obvious to others involved in the testing and review process.
Seek assistance from QA Lead, Project Manager, and/or Project Sponsor as necessary to complete responsibilities.

Quality Assurance Lead(The QA Lead and/or designee is responsible for overall quality assurance and test coordination across the team.These responsibilities include assisting team members that are having difficulty with their assignment, and hand-on correction as needed.) /

Maintain a log of testing results and assign/track problems to completion.
Work with the other team members to resolve any deficiencies and/or problems.
Work with users to coordinate and review results of User Acceptance Testing and with team members to get problems and modules re-submitted for re-testing.
Review of test documentation, including detailed user test plans, test data, and testing results.
Plan, coordinate, and monitor overall test progress and adherence to schedules; assign schedules to individual module developers.
Escalate any non-resolved issues to the Project Manager.

Program Area Tester
(The Program Area Test is responsible for assisting in creation and execution of user acceptance testing in accordance with the project and testing plans.) /

Assist in creation of test scripts and cases based on business requirements of system and process features and functions.
Execute test scripts and cases, including documenting the test results and any identified bugs.
Work with project team members to resolve and deficiencies and issues.
Signoff at the completion of User Acceptance Testing confirming all testing results meet the business requirements and may be promoted to production.

4.2Hardware/Software/Other Tools

Identify exact specifications of hardware and software required to support testing. This section should include non-standard hardware or software needed when the product is implemented or entered into production. These tools need to be tested along with the product.Summarize any significant configuration efforts, special environmental requirements, etc

5Testing Phase Timeline

<Refer to overall project schedule with testing activities or provide a high-level summary of activities, dates, and resources/owners.Schedule the testing environmentsand modules planned for conducting the individual tests.

Activity / Start Date / Target End Date / Resource
/Owner

6Approach

<List what new aspects you will be testing and what old aspects you will be re-testing. Make sure to detail the purpose for each test.You can use software application inventories, IEEE guidelines, and other sources to help you determine this list.

The test approach is an iterative process that validates all aspects of the testing effort to ensure that the product operates as per the functional and technical design specifications.The testing process consists of the following three primary periods (Planning, Preparation, and Execution) and the Bug Tracking process.

6.1Test Planning

Tasks are completed to develop the whole testing approach: develop test strategy, define test objectives, identify needed resources, plan the test environment, define test procedures, define test cases, design test data, and finalize the test plan.

6.2Test Preparation

Tasks are completed to prepare for the testing effort: creation of test data, test environment is prepared, the test plan is completed, the resource plan is completed, test reporting process is established, bug tracking process is established, and testers are trained.

6.3Test Execution

6.4Bug Tracking

<This section describes the process for tracking bugs identified during testing. The test cases for each phase of testing include a description of the expected results. The descriptions of the expected results will be compared to the actual results. A “failure” to meet the expected results will be identified as a bug and tracked in a tool (such as TFS or the Bug Tracking Log). This activity should also include retesting of “fixed” bugs. Impact should include any revisions necessary to training documentation and/or user guide materials.

7Test & Acceptance Process

<This section should be tailored to meet this project’s test and acceptance process. Please see the DOH Test Process Guidefor more information. This section includes the types of testing and phases of testing that will be included – unit testing, integration testing, regression testing, load/stress testing, etc.. Describe in general the expected results of the test set.

At the lower levels, these tests will focus on direct testing of interfaces between software functions and modules, between software functions or modules and specific electronics, etc. As more of the system is put together, tests will continue to be concerned with verifying interfaces, but will include more of a "functional test" flavor.

At each step, specify where re-running of tests from previous steps may be required to verify that integrating this new element has not caused previously tested functions to fail.

Define the process for rework, review, and retest of any element needing modification. This process must include sufficient retest to verify that any modifications have not impacted other functions already tested. This process must also define the project guidelines for how related design and requirements documents will be updated as changes are made. Change management processes for this phase must be defined and followed. Define criteria for suspending testing before completion (for instance, the discovery of major problems with a certain feature), criteria for restarting testing following such a suspension, and the criteria for determining that integration test is complete and system test can begin.

These criteria will guide your testing staff so that they know whether testing objectives have been achieved. This section can also include “exit criteria,” so that your staff know when it is acceptable to stop testing a certain feature.You should also include a list of suspension criteria and resumption requirements. This information tells testers when to pause tests and what the acceptable level of defect is to resume them.>

8Deliverables

These documents are the data, reports, scripts, and results that will be produced by testing.It’s a good idea to assign these deliverables to “owners” who are responsible for their delivery.Assign deadlines by which they are due.

Deliverable / Location / Description
Test Cases/Log
*Note –MTM (test manager) may be used in place of this log. / <Enter location of SharePoint site here> / Includes expected results, which reflect all requirements in the Detailed Requirements Document.
Updated during testing to include the status: date tested, results (pass/fail), and tester
Updated Requirements Traceability Matrix (RTM) / <Enter location of SharePoint site here> / All requirements with acceptance criteria. This will need updated to include the tests that are mapped back to the requirements.
Issue/Bug Tracking Log
*Note -TFS may be used in place of this log. / <Enter location of SharePoint site here> / Log detailing bugs while testing and the “fixes”, so that the test cases may be completed successfully.

9Appendix

<enter project code & name>
Test Plan v X.X / Page 1 of 13 / Printed: 1/23/2019