Integrated Test Plan

Regardless of what type of project you are working on, you want to catch errors as early in
the lifecycle as possible. There are projects that purposefully blast through the Analysis,
Design and Coding Phases with a philosophy that they will fix all the problems in testing.
This usually leads to disasterous outcomes.

The test plan includes the expectations for testing that will occur during the entire project. The attached
test plan is very simple. Developers should be responsible for unit testing only to ensure that their work is
quality work. Integrated testing and system testing should be done by the technical team (sometimes
developers are included in this group.) The User Acceptance testing needs to be completed by the users
or customers. Their test scripts based on the system’s requirements should be developed to ensure the
system will meet user needs. The testing/requirements process is as follows:

Notice that the system is being

developed while the user acceptance
test plans are being written. This
forces a segregation of duties and
removes testing from the responsibility
of the person(s) that developed the
system.

Quality checkpoints may be added to

this process flow diagram to ensure
that the test plans and scripts are in
sync with the software as it’s
developed.

Project Name:

Project Manager: Phone:

1 Objectives
This section defines the anticipated
outcome from the testing, the
purpose for each level of testing
that will be performed, and the
stakeholder classes (developer,
analyst, user…) responsible for the
testing. Any discussion about the
project, its goals or
assumptions/constraints on testing
should be noted here

Copyright 2010 VBH Consulting, Inc. Page: 1

Permission is granted to use, modify and distribute this document
Integrated Test Plan

2 Unit test
The purpose of unit testing is to ensure that each individual module or unit in the system
satisfies quality standards and the system requirements that apply. This section describes the
type of testing that is expected of the developer. Unit testing, while very important, is not
often structured. The lack of structure lends to a possibility of bugs slipping through unit
testing. This plan may be the only written expectations for unit testing. The business analyst
(or project manager) should be explicit about how the software (or modules) should be
tested.

2.1 Requirement(s) satisfied by the module

List the requirements that are satisfied by the module(s) included in the test. This
section may be repeated several times based on the number of testing categories or
units to be tested.

2.2 Unit or Module description

Include the name of the module, responsibility for developing and testing the
module.

2.3 Test procedures

White Box and Black Box testing:
In white box testing, you look at the structure of the internal code and try to create
test data that will exercise all of the code (or as much of the code as possible). For
instance, whenever you have a conditional logic statement (IF-THEN-ELSE), you
want to generate a test case that will ensure that each branch of the code is
executed. White box testing is complementary to black box. You would not want to
limit your unit testing to white box only. The biggest problem is that just because
each part of the code is exercised does not mean that the results are accurate.
Black box testing looks at the program's functionality against the business
requirements rather than the internal lines of code. Black box testing implies that
your program is literally a black box. You are not concerned with its inner
workings. All you know is that when you give it a certain set of inputs, it gives back
a certain set of outputs. This is true whether the program is a report, a webpage, or
an internal calculating procedure. All programs work on some set of inputs and
create some set of outputs.
Note that the unit testing is almost always done by the original programmer. So,
although black box testing implies that you do not know the interior workings of the
program, the original developer obviously will. This can make it more difficult to
do black box testing since the original programmer may have certain biases in his
or her understanding of the component that may influence how he or she conducts
the testing. However, even given the potential biases and assumptions, this type of
testing is still fundamental to a good unit test.

2.4 Exit criteria

Define the acceptable level of test.

Copyright 2010 VBH Consulting, Inc. Page: 2

Permission is granted to use, modify and distribute this document
Integrated Test Plan

3 Integration/Regression Test (Systems test)

The purpose of the integrated test is to retest the units as well as ensure that they perform
together in the existing environment. Stress testing or volume testing may be required at this
time. The purpose for Regression testing is to ensure that “what used to work, still works”
after the new modules are put in place.

3.1 Requirements satisfied

This section usually defines the requirements that will be tested in each round of
tests. There may be multiple modules and multiple requirements included in one
test. Non-functional requirements are usually defined tested during the integrated
or regression tests.

3.2 Testing responsibility

Who will be responsible for conducting the test. This can be an individual or a
group of project team members.

3.3 Test procedures

This section defines the tests and how they will be performed. The purpose for this
plan is to ensure that the environment and resources are available to accomplish
the tests at the right time. Some questions to answer in this section are:
How will the test be completed? What platform will we used to ensure changes are
not made during our tests? What interfaces will be tested? How many ‘tests’ make
an acceptable level of test?
Test scripts are usually not included in the plan, they are usually a separate
detailed document.

3.4 Exit criteria

Define the acceptable level of test. May include a checklist to specifically note the
areas that should be tested successfully.

3.5 Test tools

If there are any special tools to aid in the system or integrated test, note them here.

4 User Acceptance Test

The final stage of testing should be the Acceptance test. If the Unit and Systems tests were
completed successfully, there should be no bugs in the Acceptance test. The purpose of the
User Acceptance test is to verify that the developed system meets the needs of the users. The
user acceptance test portion of the test plan is usually completed by the customer or users of
the system. This test demonstrates whether the system can operate under the conditions
agreed to by the customer. At the end of user acceptance testing, the user and customer have
accepted the delivered system.

Copyright 2010 VBH Consulting, Inc. Page: 3

Permission is granted to use, modify and distribute this document
Integrated Test Plan

4.1 Requirements satisfied

This section defines the solution requirements (usually functional requirements)
that will be tested in each test. There may be more than one requirement tested in
this test.
There may also be many rounds of tests. The Test Plan needs to be specific about
what will be tested, if it’s not specified, the test will probably not happen.

4.2 Testing responsibility

Who will be responsible for conducting the test. This can be an individual or a
group of project team members.

4.3 Test procedures

Determine the testing environment, how may tests will be accomplished, will there
be a sign-off as the tests are completed? Test scripts are not included in the plan,
they are a separate, detailed document.

4.4 Exit criteria

Define the acceptable level of test. You may also include the acceptance sign-off
requirements in this test plan. Usually a successful Acceptance test means that the
solution is ready for production… be specific about what denotes a successful test.

4.5 Test tools

5 Testing Facilities
A separate section has been provided to help the project manager, business analyst and
customer define testing facilities. Consider the following situations when scheduling
system or user testing:
Availability of Help (both technical and business-related)
User manuals – online or printed
Equipment – desks, books, computers, network
Location – conducive to testing, easily accessible for the team, possibly consider an off-site
testing facility for customers or users.
Process simulations – If there are any process changes that have been accomplished
during the development of the system, be sure to incorporate those changes into the
Acceptance testing.

Copyright 2010 VBH Consulting, Inc. Page: 4

Permission is granted to use, modify and distribute this document