Liberty University
IT Development and Engineering
Test Plan
* Revision 1.2 – 09/06/2005 – This Template is a generic template that can be used for any development at
IT Development & Engineering. The goal of this template is to collect as much relevant information as
possible so the Verification and Testing Unit, can conduct tests on the system being deployed.
The template is flexible in nature, if you need to need any information to this document that you think there
is not an appropriate location to do so, just create the space for it and add your notes.*
Project Name: * Name of Project – including any sub-projects it may have or the name of the parent
project *
Team Members: * Everyone included on the project. Project Manager, Developers, System Developers,
User Education, Customers, Product Owner, Testers, External Vendor, etc…*
Overview:
Name of Product: * If already described under project name, not necessary *
Background: * What’s this system all about? What’s its history? What are we trying to solve? Is it
a new implementation? An upgrade to a new version? What’s it suppose to solve? Etc… *
Feature List: * What are the features, components, technologies that this project has? What does
each one of them do? *
Technical Specifications: * Depending on your project not all of the options below are required. If you
need to describe other technical specs that are not listed, just add them to the list. *
Files Added/Deleted/Modified for release: * List of all files that have been created, removed, or
modified because of this project. Add file system patch (if applicable). If files can be grouped together
under different features (described above), please do so. *
Databases: * What are the tables, and database that this project uses? Did you have to modify
data, structure? If yes, which ones? *
Datasources: * List of Datasources used for this system (if applicable). Did it already exist? Did
you have to modify permissions on the DB for this particular datasource? *
Apache/IIS Modifications: * Were virtual directories have to be created? Modified? *
Server Side Language Modifications: * Any specific settings for the server side language had to be
modified? If yes, which ones? (i.e. coldfusion sandbox) *
Server Settings: * Any operating system level configuration needed to be added/modified? (i.e.
System or Share permissions?) If yes, which ones? *
External Application Modifications: * Any modification to external applications? (i.e. Web
Administrator? Web Manager?) If yes, which ones? *
Network Settings: * Any modification done to the network? (i.e. Firewalls, DNSs, IP settings, etc)
*
Security Settings: * File level, user level permissions, anything else that has to do with handling
data transfer, user authentication and validation, etc. *
Expected Results (per component): * A component could be any ‘system unit’ being produced or
configured in the system. It could be a module from Coldfusion, a Linux daemon like Apache or even a
piece of hardware like the SAN.
For every functionality/module/screen on your product there should be a predetermined expected result. If
an action happens, what is the result expected? What changes on the database? On layout? Or
configuration files? Or permissions? Include the expected results of all exceptions for each module.
Be aware that this section of the document will most likely be the longest and most cumbersome to write.
Feel free to use the help of the Verification and Testing Unit to help you find scenarios for the Expected
Results.
A good “Expected Result” description should always list the Input Values, Conditions in which those
values are going to be executed under, and the expected Output Values. Even for servers or images, the
developer must be aware of what types of request the server will be getting and what type of responses it
will be giving. Depending on the type of system load testing, security testing must be described in the
environments below.
If test team discovers anything that is not “expected” it will be considered a defect. *
Development Environment: * Describe the behavior, input/output, technical aspects of the
development version of your system. *
Test Environment: * Describe the behavior, input/output, technical aspects of the test version of
your system. This should be as close as possible to the results on Production.*
Production Environment: * Describe the behavior, input/output, technical aspects of the final
production version of your system. *
* Sometimes an application/image/server setting needs to be tweaked from development -> test ->
production, make sure to document them in the space above as well. *
Role Infrastructure: * What types of user permissions does this system have? What are the expected
results for each permission level? Any other type of permissions that describe the role of the users on this
system? If yes, explain the expected results, how to manage them, etc… *
List of roles and description of each
Scheduling: * What’s the estimated timetable for Testing/Deployment to happen? It is good practice to
have testing done once the application has been deployed to production. Make sure to allocate time for that
as well. This time table should be given by the Project manager. *
Date for testing to be completed:
Date for testing on deployment to be completed:
Date for deployment to be completed:
Date for testing on production to be completed:
Checklist: * After creating this document, can you answer all of these questions with a positive answer? *
Can a person not related to this project, read this document and have an overview of what you are
trying to accomplish?
Will a person know what the time frames for Testing, Deployment and Go Live Date are?
Are all the files/configurations/permissions necessary for a successful deployment listed on this
document?
Will a person be able to understand the expected results of each component of this project?
Have you listed expected results for invalid inputs? Or abnormal conditions?