<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

03/10/2016
Page 1 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Executive Summary
Objective
<The objective of this document is to define the test plan of the <Project Name> for
Phase/Release <#. #>>

Overview
<Please include a brief overview of the testing phases here.>
The Table below defines the various test phases and who is responsible for their execution. <If
any of the following test phases are not applicable, or if any additional test phases are planned,
please update the table accordingly.>
Table 1: Test Phases

Phase

Responsible
Perso
n(s)

Description

Unit Test

Developers

Integration Test

Developers / Track Tests integrated modules within a subsystem or

Lead
functional area and integrated modules among
subsystems or functional areas.

System/
Performance
Test

Performance Test
Team

Acceptance Test Acceptance Test

Team

Tests an individual module in an isolated environment.

Tests production hardware and software configuration

performance. Tests the overall system independent of
user involvement. The emphasis is on correct
functionality of the overall system.
Tests integrated modules among subsystems or
functional areas. Acceptance test is similar to system
test in both form and function, but it introduces users to
the testing process and ends with their approval on the
correct functionality. Its emphasis is on meeting
requirements, the user interface, correct functionality,
and utility from the end users perspective. It is
complete when the project sponsor agrees to proceed
with production implementation.

Page 2 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

The following chart highlights the steps that will be completed as part of each testing phase.
<Please add any additional charts to highlight the various steps in other testing phases.>
Testing Steps

Develop
Test
Cycles

Identify
Test
Conditions

Develop Test
Scenario
Objectives

Preparation

Prioritize Test
Scenarios

Determine
appropriate
coverage

Detail Test
Scenarios,
Scripts,
Results

Identify Test
Data

Scenario
Development

Execute
Test
Scenarios

Log,
Prioritize,
Resolve
Problems

Manage
Environment

Test Execution

Testing Scope
<Describe the scope of testing here i.e., what testing will verify/validate, and how.>

Page 3 of 18
SDM Test Plan Template

Provide
Readiness
Assessment

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Unit Test Plan

Definition
<Unit testing is the process of testing an individual, low-level program in an isolated
environment before testing its integration with other units. Unit testing verifies the code object
matches the technical design, properly handles the data and the available paths through the
software execute reliably. This testing is typically performed on the developers workstations,
and then repeated on the server-based development environment. Limited interfacing of
components is likely to occur in this phase by a developer.>

Objective
<The purpose of unit testing is to find code defects in functions or in a unit of work. Unit testing
is the most efficient, effective, and inexpensive phase in terms of defect detection.>

Depth of Testing
<Unit test plans should cover the technical details of the program. Expected results focus
on internal code and the inputs and the outputs from the code. In-depth, high-quality unit
testing will shorten future testing phases by reducing the defect rate.>

Approach
<The unit test technical approach is to validate the following: internal logic, error handling, field
processing, computations/calculations, data handling/access, range of possible inputs/outputs,
and cross-field edits. Using the application documentation as a guide, the developer moves
through the code he/she has written and ensures all the requirements and the coding standards
have been met. Best practices provide that the developer will engage peers to review his/her
code.>

Page 4 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Roles and Responsibilities

<Complete the following table for the roles and responsibilities for this testing phase.>
Testing Activities
&
Envir
onme
nt

Resources
Requ
ired

Date

Create / Update
Scenarios

Functional
Team Lead

Delivery Responsibilities

Products:

Test Scenarios

Responsibilities:

Create Test Data

Functional
Team

The functional team will develop the

integration test scenarios prior to
beginning the design of integration test.
Business Logic Descriptions and unit test
cases will be used as a starting point

Test Data
<List all required test data here to be used in Unit Test.>

Entry Criteria
<List or reference the baselined program specifications, development standards, and other
source documentation that will be the entry criteria for Unit Testing.>

Peer Review complete

Adherence to specifications verified

Walkthrough with the design analyst/project manager complete

QA/Exit Criteria
<Describe the QA/Exit Criteria of Unit Testing here.>

Adherence to coding standards verified

Updates to specifications made based upon discovery are required and complete

Completed module checked into Microsoft (MS) SourceSafe or maintained in the Project
Folder
Page 5 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Preliminary interface testing complete, documented, and maintained in the project folder

Readiness assessment complete

Page 6 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Unit Test Activities

Developer self-review - The developer must ensure his/her code is functional before
requesting any type of testing. The objective is to reduce the amount of time spent on
corrections later in the process.

Create Unit Test Checklist based on the items being tested as well as the test
scenarios, the Developer works with the project manager/track lead to create the Unit
Test Checklist

Revise and approve Unit Test Checklist the project manager/track lead then revises
and approves the new version of the Unit Test Checklist

Perform Unit Test of developed code

Perform check against coding standards

Perform check against best practices

<Add any additional Unit Test activities here.>

Unit Test Goals To verify adherence to:

Business requirements

Screen standards

Code standards

Graphic design standards

File naming conventions

Best practices (e.g., reusability, efficiency)

Project standards (adherence to nomenclature and interfaces)

<Add any additional Unit Test goals here.>

Page 7 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

System & Integration Test Plan

Definition
<System testing is a comprehensive, end-to-end test of the integration of subsystems and
interfaces. System test scenarios model valid business activities. Typically, load testing, stress
testing, and regression testing can also be incorporated in this plan. Testing tools where
relevant can be included. Tests should be documented and maintained in the Project Folder so
they can be repeated in future iterations or prior to future releases. Add any further definition
here.>

Objective
<System testing ensures that subsystems and interfaces function and interact according to
design. The purpose of integration testing is to verify proper coordinated functioning of the
modules that make up a sub-system. The focus of integration testing is on cross-functional
tests rather than on unit tests within one module.>

Depth of Testing
<This should be prioritized by functionality with more time and resources being invested in
critical areas. During system testing, proper end-to-end functionality needs to be tested and
validated. In addition to testing for proper functioning under normal conditions, testing will
also emphasize responses to bad data, out-of-bounds input, and other abnormal
conditions.>

Approach
<The approach to system testing should model the actual usage of the application in production.
Valid business processes, including inputs and outputs, are executed and validated. Online and
batch activities occur as of a simulated date and time to allow for testing of date/time driven
logic. End-to-end testing needs to be performed to verify the system will function according to
requirements. Environment management is a significant portion of the system test effort.
Managing backups, restores, configuration data migration, build deployments, build
shakedowns, etc., and must be factored into the effort. Integration testing focuses on the valid
interactions of units or driven flow that must execute successfully to satisfy a business process.
This includes but is not limited to: window navigation within a subsystem, data passage within a
subsystem, error handling, security and controls, interfaces and data transfer, and outputs
(reports, forms, and correspondence). This phase includes both positive and negative testing.
In addition, it includes unit test criteria; as well as, criteria that cannot be tested within an
independent unit. It should show that unit components tested now interact correctly according
to the design. Again, the approach may vary for online, batch, package, Internet, etc., modules.
Alternate test approaches; including queries, database validation, etc., may need to be
incorporated.>

Page 8 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Roles and Responsibilities

<Complete the following table for the roles and responsibilities for this testing phase.>
Testing Activities &
Environ
ment

Resources
Requ
ired

Date

Delivery Responsibilities

Test Data
<List all required test data here to be used in System & Integration Test.>

Entry Criteria
<Describe program specifications/development standards or other items that will be the entry
criteria for System Testing.>

Unit Test documentation

<Add any additional entry criteria here.>

QA/Exit Criteria
<Describe the QA/Exit Criteria of System & Integration Testing here.>

Completed test plan documentation

Updated unit, integration, and system test plans based upon discovery

Page 9 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

System & Integration Test Activities

Developer self-review - The Developer must ensure that his/her code is functional before
requesting any type of testing. The majority of this self-review will happen while the
Developer is coding the objects. However, it is recommended the Developer take time
to verify the validity of his/her code before moving it along in the testing process to
reduce the amount of time spent on corrections and project Change Requests (CR) later
in the process.

Perform Integration Tests of the developed code

Update application specifications, unit, integration system test plans based upon
discovery

Testing for Functionality - Functionality testing deals with the business requirements of
the application. During this sub-phase, the tester is performing scenarios that attempt to
discover problems in the operation of the application. Problems found here are typically
the most serious, because they directly affect the ability of the application to meet the
demands of the client.

Test for JavaScript Reliance - The application will make heavy use of JavaScript to
validate form data and handle some light processes (such as displaying the current
date.) However, because the client platform will not be standardized, the possibility
exists that the user will not have JavaScript enabled. The application must perform
adequately when this situation occurs. Therefore, it is essential that scenarios be
developed to traverse the application with JavaScript disabled.
This testing must occur after Functionality Testing to gather a baseline of correct
behavior and output when JavaScript is enabled.

Test for Browser Compatibility - The Web-based Worker Interface will support multiple
browsers. Therefore, it is imperative that the application works the same (within reason)
regardless of browser or version. This testing is done after functionality has been proven
so that a baseline of correct operation is available. The current approved version of
Microsoft Internet Explorer will be used as the baseline
Test for Accessibility - The developed site must conform to accessibility guidelines.

<Add any additional System and Integration Test activities here.>

Page 10 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

System & Integration Test Goals To verify adherence to:

Business requirements

Screen standards

Code standards

Graphic design standards

File naming conventions

Best practices

System and module standards, e.g., Section 508 compliance, thematic requirements
and documentation requirements

<Add any other planned System & Integration Test activities here.>

Page 11 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Load Test Plan

Definition
<Load testing observes production hardware and software configuration performance under a
predetermined set of test scenarios to confirm that the system, as built and deployed, can
maintain adequate throughput, satisfactory response, and timely operation under different stress
and volume conditions as are likely to occur in production. This is normally part of system
testing.>

Objective
<The purpose of Load Testing is to determine whether, or at what point, extreme conditions are
likely to cause system failure.>

Depth of Testing
<This should be prioritized by functionality with more time and resources being invested in
critical areas. Testing should include scenarios simulating maximum hardware and software
usage that are likely to occur infrequently over the life of the application, (e.g., before or after
holidays, during weekends, at months end, at quarters end, or at years-end processing).>

Approach
<The approach should focus on validating the performances and stress with the operations and
business processes that users employ daily.>

Roles and Responsibilities

<Complete the following table for the roles and responsibilities for this testing phase.>
Testing Activities &
Environm
ent

Resources
Requ
ired

Date

Delivery Responsibilities

Page 12 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Test Data
<List all required test data here to be used in Load Test.>

Entry Criteria
<List any program specifications/development standards, scenarios, or other items that will be
the entry criteria for Load Testing.>

QA/Exit Criteria
<Describe the QA/Exit Criteria of Load Testing here.>

Statement of Results

Deficiencies in testing

Updated Detailed design, Program Specifications, and test plans based upon discovery

Page 13 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

User Acceptance Test Plan

Definition
<User Acceptance Testing is similar to the system test in both form and function. However, User
Acceptance Testing introduces users into the process. UAT should be performed last to ensure
that the final version of the application meets all of the guidelines.>

Objective
<The purpose of User Acceptance Testing (UAT) is to validate that the system is usable and to
gain client sign-off.>

Depth of Testing
<This should be prioritized by functionality with more time and resources being invested in
critical areas. In addition to testing for proper functioning under normal conditions, testing will
also emphasize responses to bad data, out-of-bounds input, and other unusual conditions.>

Approach
<The approach focus on validating the system interaction with the operations and business
processes users employ daily and to verify that the requirements are met.>

Roles and Responsibilities

<Complete the following table for the roles and responsibilities for this testing phase.>
Testing Activities &
Environm
ent

Resources
Requ
ired

Date

Delivery Responsibilities

Page 14 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Test Data
<List all required test data here to be used in User Acceptance Test.>

Entry Criteria
<List any program specifications/development standards, predefined scenarios, or other items
that will be the entry criteria for User Acceptance Testing.>

QA/Exit Criteria
<Describe the QA/Exit Criteria of User Acceptance Testing here.>

Updated User Acceptance Test Plan

User Acceptance Testing Activities (UAT)

Examples of UAT activities include:

Execute tests to prove functionality

Execute tests based upon the user case scenarios

Document and resolve improper functionality

<Add any additional activity here>

User Acceptance Goals To verify adherence to:

Business requirements and expected functionality

Interface requirements

Page 15 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Defect Management Process

<Provide details as to how defect management should be carried out. This includes how
defects are to be tracked, who the contacts are, which developers are assigned, the turnaround
time for re-testing, and the approval process for corrections. Also, the refactoring (or the
updating and correction of a process and its documentation) process can be addressed here as
defects often result in the discovery of deficiencies in the project documentation. This is also
commonly referred to as the problem reporting and resolution process.>

Page 16 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>

Appendix A Testing Calendar

The calendar on the next page, illustrates the timing of the tasks for both system integration and
acceptance testing.
Currently used abbreviations include:
Abbreviation

Meaning

DEV

Development

INTG

System Integration Testing

SAT

System Acceptance Testing

UAT

User Acceptance Testing

USR

User Administration

TFP

Test for Production

TRN

Training

Functional Team Lead

All Integration Testing will take place at the following location:

<Include address where Integration Testing will take place.>

All System Acceptance Testing will take place at the following location:

<Include address where Acceptance Testing will take place.>

Page 17 of 18
SDM Test Plan Template

<Project Plan> - SDM Test Plan

Last Update: <Insert Date>
<Insert the calendar here. The calendar is to show the testing events, team leads and contacts,
and the date and time for each event.>

Sept.
Sun

Mon

An Example of a Testing Calendar

Tue

Wed

Thu
1

Fri
2

Sat
3

Unit
Testing in
Progress
4

10

INTG

11

12

13

14

15

16

17

18

19

20

21

22

23

24

SAT

25

26

27

28

29

Page 18 of 18
SDM Test Plan Template

30