Test Plan
Table of Contents
1.
2.
3.
4.
IDENTIFIER………………………………………………………………….2
INTRODUCITON…………………………………………………………….4
ITEMS TESTED…………………………………………………………......5
APPROACH………………………………………………………………….5
4.1 Introduction……………………………………………………………5
4.2 Strategies and Techniques…………………………………………….5
4.2.1 Code Testing……………………………………………6
4.2.2 Testing User Requirements……………………………6
4.3 Tools Used………………………………………………………………6
4.4 Expectations…………………………………………………………….6
5.
TEST DELIVERABLES…………………………………………………..…7
5.1 Introduction……………………………………………………………7
5.2. Deliverables…………………………………………………………..7
5.2.1 Test Specification………………………………………………..7
5.2.2 Incident Reports…………………………………………………7
5.2.3 Defect Reports…………………………………………………...7
5.2.4 Change Reports………………………………………………….7
6.
TESTING TASKS……………………………………………………………7
6.1 Introduction………………………………………………………………...7
6.2 Tasks ……………………………………………………………………….7
6.3 Dependencies. ………………………………………………………………8
7.
SCHEDULE…………………………………………………………………..8
7.1 Introduction…………………………………………………………….8
7.2 Schedule…………………………………………………………………8
7.3 Milestones……………………………………………………………….9
8.
REQUIRED RESOURCES………………………………………………….9
8.1 Introduction……………………………………………………………..9
8.2 Resources Used………………………………………………………….9
8.2.1 Electronic Resources……………………………………9
8.2.2 Human Resources………………………………………9
8.2.3 Other…………………………………………………….10
Authors:
Ryan Johnson
Sepideh Dehghani
Kam Walia
Jason Eastburn
Michael Nadrowski
Adnan Syed
1. Identifier
This standard describes a set of basic test documents that are associated with the dynamic
aspects of software testing. The standard defines the purpose, outline, and content of each
basic document. While the documents described in the standard focus on dynamic testing,
several of them may be applicable to other testing activities.
This standard is applied to HHN because it runs on any type of computer such as digital.
Applicability is not restricted by the size, complexity, or criticality of the software.
However, the standard does not specify any class of software to which it must be applied.
The standard addresses the documentation of both initial development testing and the
testing of subsequent software releases. For HHN software release, it may be applied to
all phases of testing from module testing through user acceptance. However, since all of
the basic test documents may not be useful in each test phase, the particular documents to
be used in a phase are not specified. Each organization using the standard will need to
specify the classes of software to which it applies and the specific documents required for
a particular test phase.
The standard does not call for specific testing methodologies, approaches, techniques,
facilities, or tools, and does not specify the documentation of their use. The standard also
does not imply or impose specific methodologies for documentation control,
configuration management, or quality assurance. Additional documentation (e.g., a
quality assurance plan) may be needed depending on the particular methodologies used.
Within each standard document, the content of each section (i.e., the text that covers the
designated topics) may be tailored to the particular application and the particular testing
phase. In addition to tailoring content, additional documents may be added to the basic
set, additional sections may be added to any document, and additional content may be
added to any section. It may be useful to organize some of the sections into subsections.
Some or all of the contents of a section may be contained in another document which is
then referenced. Each organization using the standard should specify additional content
requirements and conventions in order to reflect their own particular methodologies,
approaches, facilities, and tools for testing, documentation control, configuration
management, and quality assurance.
1.1 References
This standard shall be used in conjunction with the following publication.
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
1.2 Definitions
This clause contains key terms as they are used in this standard.
1.2.1 design level: The design decomposition of the software item (e.g., system,
subsystem, program, or module).
1.2.2 pass/fail criteria: Decision rules used to determine whether a software item or a
software feature passes or fails a test.
1.2.3 software feature: A distinguishing characteristic of a software item (e.g.,
performance, portability, or functionality).
1.2.4 software item: Source code, object code, job control code, control data, or a
collection of these items.
1.2.5 test: (A) A set of one or more test cases, or (B) A set of one or more test
procedures, or (C) A set of one or more test cases and procedures.
1.2.6 test case specification: A document specifying inputs, predicted results, and a
set of execution conditions for a test item.
1.2.7 test design specification: A document specifying the details of the test approach
for a software feature or combination of software features and identifying the
associated tests.
1.2.8 test incident report: A document reporting on any event that occurs during the
testing process which requires investigation.
1.2.9 testing: The process of analyzing a software item to detect the differences
between existing and required conditions (that is, bugs) and to evaluate the features
of the software item.
1.2.10 test item: A software item which is an object of testing.
1.2.11 test item transmittal report: A document identifying test items. It contains
current status and location information.
1.2.12 test log: A chronological record of relevant details about the execution of
tests.
1.2.13 test plan: A document describing the scope, approach, resources, and
schedule of intended testing activities. It identifies test items, the features to
be tested, the testing tasks, who will do each task, and any risks requiring
contingency planning.
1.2.14 test procedure specification: A document specifying a sequence of actions
for the execution of a test.
1.2.15 test summary report: A document summarizing testing activities and results.
It also contains an evaluation of the corresponding test items.
2. INTRODUCTION
2.1 Objectives
A system test plan for HHN should support the following objectives:
1. To detail the activities required to prepare for and conduct the system test.
2. To communicate to all responsible parties the tasks that they are to
perform and the schedule to be followed in performing the tasks.
3. To define the sources of the information used to prepare the plan.
4. To define the test tools and environment needed to conduct the system
test.
2.2 Background
The Healthy Homes Network of Greater Kansas City (HHN) is a community-based,
nonprofit organization dedicated to the promotion of safe and healthy homes. Over one
hundred individuals, representing more than fifty nonprofit organizations, public
agencies, universities, hospitals and neighborhood groups, are collaborating to help
residents of metropolitan Kansas City access information and services that will allow
them to improve the quality of their lives.
Working in conjunction with the staff at Children’s Mercy Hospital’s Center for
Children’s Environmental Health, the HHN will identify children eligible for the grant,
assess the environmental health of the home, survey the physical health of the child, and
provide extensive, individualized education to the family. Local contractors will then
perform low-cost repairs based on the results of the initial assessments and surveys. Six
months after the completion of the repair work, assessments and surveys will be repeated
and the results will be scientifically evaluated to determine the health impact of low cost
remediation coupled with in-home education.
In addition, the grant will allow the HHN to operate walk-in resource enters, a website
and search-enabled database, as well as provide extensive outreach and training on a
variety of topics. The university of Missouri-Kansas City and The Center for the city will
provide planning and technology assistance toward the development of resource centers
for residents who are interested in accessing information and services related to creating
and maintaining safe and healthy homes.
3. ITEMS TESTED
Items tested are the specific work products to be tested. The specification will be the
source for establishing expected results. The versions to be tested will be placed in the
appropriate libraries by the configuration administrator. The administrator will also
control changes to the versions under test and notify the test group when new versions are
available.
The following documents will provide the basis for defining correct operation:
 HHN system statement of Requirement Document
 HHN system statement of Project Plan
 HHN system statement of Architectural Document
3.1 FEATURES TO BE TESTED
The following list describes the features that will be tested:
 Database conversion
 Requirements Document
 Architecure
 Source Code
 Security
 Recovery
 Performance
3.2 FEATURES NOT TO BE TESTED
All the features that will not be used when the system is initially installed will be
included in this section.
4. APPROACH
4.1 Introduction
This section explains strategies, techniques, and tools that were used during our
tests. The amount of time, effort as well as our goals and expectations required to
complete tests are also specified in this section.
4.2 Strategies and Techniques
Our goal is to find defects. Whether we are testing a particular user requirement,
performing simple regression test, or simply testing portion of the actual code, it
is imperative that we follow a proper testing scenario.
Different tests require different testing scenarios. In this document, however, we
will focus on techniques and tools that we have adopted during tests performed by
our tester and developers.
4.2.1
Code Testing
The time and effort that was put on testing the actual code varied and
largely and depended on the complexity of the code. For example,
connecting to the Access Database using ASP code was tested within 5
minutes. Function “ADD”, on the other hands, required thorough testing,
including unit testing as well as integration and regression testing and took
about as much time as writing the code itself.
The strategy that we adopted for code testing was largely based on unit
tests done by the programmer and then regression test using the client
code.
4.2.1
Testing User Requirements.
User requirements have been initially tested at the beginning of the
project. The strategy we have adopted during requirements testing was
very simple and yet effective. It was based on conducting informal
meetings, where team members expressed their concerns and opinions on
particular user requirement. Use cases were also thoroughly analyzed.
Usually the meetings lasted 30minutes to 1hour.
4.3
Tools Used.
The code testing was performed using various software. Macromedia
Code Inspector was one of them, and so was Microsoft Visual
Studio .NET.
4.4
Expectations
We expect to find defects or potential defects. We are coming out of
presumption that our software has errors and it is our job to find them as
quickly as possible.
5. TEST DELIVERABLES
5.1 Introduction
This section outlines main testing deliverables including test specification,
incident reports, defect reports and change reports.
5.2 Deliverables
The main deliverable of the Test Plan is of course this document. However there
are other important deliverables that provide valuable information.
5.2.1
Test Specification
Test specification are included in separate document titled Test Specification.
Test Specification document outlines Unique Identifiers, Items and Features
Tested, Inputs, Expected Output and Test Procedure.
5.2.2
Incident Reports
A test case failure creates an incident. The incident may or may not be
caused by a defect. Incidents are detailed in the Test Specification
Document.
5.2.3
Defect Reports
Defect Reports along with Incident Reports are analyzed in the
Test Specification Document.
5.2.4
Change Reports
Change in any reports, including this one, will be done in formal way. A copy
the new document with changes will be provided among group members and
also online version will be updated.
6. TESTING TASKS
6.1 Introduction
This section outlines individual tasks required to complete the testing effort
including dependencies between tasks.
6.2 Tasks
Testing Tasks
Verifying User
Requirements
---Use Cases
Verifying Correctness of
the Architecture Scheme
Testing Software
Implementation
---ADD function
--DELETE function
--MODIFY function
--Hit Counter
--Database
Implementation
Tester
Requirement
Engineer / Group
Requirement
Engineer / Group
Architect
Start date
Completion
Date
09/08/03
09/11/03
09/15/03
09/25/03
10/16/03
11/06/03
09/25/03
09/25/03
06/30/03
09/29/03
10/20/03
09/25/03
06/30/03
07/09/03
10/02/03
10/23/03
10/23/03
10/30/03
Week of
11/09/03
Developers/Group
Developers/Group
Developers/Group
Developers/Group
Developers/Group
Developers/Group
6.3 Dependencies
There are few dependencies that that are worth noting. First, the Verification of
the User Requirements had to be done as a first step. That was done by
Requirements Engineer along with the support from the Group during the first
week of the project. Also Use Cases were thoroughly tested.
Next Architect verified the correctness of the architecture scheme that we as a
group have pre-selected (3-Tier Architecture). Then, and only then we could
proceed to Implementation phase. Code inspection was done mainly by
Developers and verified with during the Regression tests by the Group.
7. SCHEDULE
7.1 Introduction
This section outlines schedule for completing Test Cases outlined above. It also
shows the amount of effort a particular task took as well as major milestones of
Testing Phase.
7.2 Schedule
Week of
11/16/03
W
1
Testing Tasks
Verifying User
Requirements
---Use Cases
Verifying Correctness of
the Architecture Scheme
Testing Software
Implementation
---ADD function
--DELETE function
--MODIFY function
--Hit Counter
--Database
Implementation
Testing Effort
Prediction
Acctual
Intermediate Intermediate
/Hard
Intermediate Intermediate
/Hard
Intermediate
Easy
Intermediate
Hard
Intermediate
N/A
N/A
Intermediate
Easy
Intermediate
N/A
N/A
Intermediate
Intermediate
Start date
Completion
Date
09/08/03
09/11/03
09/15/03
09/25/03
10/16/03
11/06/03
10/25/03
10/14/03
N/A
N/A
11/01/03
11/10/03
10/30/03
N/A
N/A
11/10/03
11/01/03
11/10/03
7.3 Milestones
Major milestones include: Verifying the correctness of the User Requirements,
verifying architecture, and validating and verifying source code.
8. REQUIRED RESOURCES
8.1 Introduction
This section outlines resources that were used during the testing phase.
8.2 Resources Used
We can divide our resources into few categories, including Electronic Resources,
Human Resources and Other.
8.2.1 Electronic Resources
Probably the most frequently used resource that was utilized during the Testing
Phase was the various software systems. We have used Macromedia Code
Inspector as well as Microsoft Visual Studio .NET. Both product allowed us to
preview the results instantaneously in web browser of our choice, therefore
making Unit Testing effortless.
8.2.2 Human Resources
Week of
11/09/03
Week
11/16
Human Resources were crucial during testing User Requirements. Expertise of
developers, as well as good managerial skills allowed us to quickly pin-point
possible defects or misunderstandings with client.
8.2.3 Other
There are other resources that we have used during the Testing Phase that do not
fall in the above categories. They include support from online resources that
allowed us to more accurately and efficiently track down errors and learn better
programming techniques.