Test Type Defnitions

1. Unit testing
Unit testing is the process of testing the smallest units of a single program. Instead of initially
testing the program as a whole, sub-programs, sub-routines and procedures in a program are
tested individually frst. This ensures that the smaller units of a program function together
properly, in the correct sequence and that loops terminate properly and switches control
processing correctly.
2. Integration testing
Integration testing is the process of ensuring programs/modules function together properly and
in the correct sequence, especially if new or changed components create output to be used as
input to other components in the system, or modify eisting data.
Integration testing is typically performed after Unit testing has been completed. In some
circumstances, Unit and Integration testing functions must share the same testing environment.
!here this occurs, ensure that the interface points with the remainder of the system are tested
frst.
3. System testing
"ystem Testing typically involves eercising all of the ma#or functions built into the system to
ensure that the system can perform/deliver its intended business and technical requirements.
$nsures that additions/changes do not interact adversely with operational modules as well as
modules undergoing development during the same time. %$& other pro#ects included in the
same release'. (oncurrent development pro#ects should always be tested together prior to
installation.
4. Acceptance testing
)cceptance Testing is the process of determining whether or not all of the original ob#ectives,
requirements and epectations of the pro#ect have been met. "omeone *nowledgeable of the
$nd User perspective %perhaps the end user themselves' performs this type of testing.
)cceptance testing is the last pass against the system before it is promoted to the operational
environment. %+or eample, may include negative and regression testing'.
If applicable, a separate group %outside of the ,-.' may perform the )cceptance testing.
Release Date: 03/11/02 Page 1 of 3 Version 1.0
Examples of Additional Testing onditions!Scenarios
/ou may want to consider the following types of test conditions. These may be included in any or
all of the above types of testing. $amples of the types of testing in which these scenarios could
begin to be used are included in parentheses. )ll of the following test conditions are a g"ideline
and are not required.
#egression Testing %Unit'
0erformed after ma*ing a functional improvement or repair of the software to determine if
changes have compromised the integrity of the eisting functionality. 1egression testing verifes
that areas of the system not a2ected by the software remain unchanged and correct. )nalysis of
the system must be conducted, as the pro#ect is developed in order to determine which areas
have the highest potential to be a2ected.
$egati%e Testing %Unit'
Testing designed to verify that things the pro#ect states are not allowable or are outside the
specifed value range are 3-T being permitted. +or eample, if a feld is supposed to be numeric,
a negative test would prove that alpha or non-numeric characters are not permitted.
&erformance and E'ciency Testing %Integration'
"howing that a program or system meets pre-defned performance and e4ciency ob#ectives,
such as specifc response times, throughput rates under certain wor*load and confguration
conditions, online fle availability or report print/distribution times. Included in this could be co-
habitation testing which is the process of verifying that the system will function properly when it
shares hardware or software facilities with eisting systems.
(ol"me Testing %Integration'
"ub#ecting a program/ system to normal or epected production volumes of data to prove that
the program/system can handle the data.
Stress Testing %Integration'
"ub#ecting a program or system to heavy loads or stress. )s opposed to volume testing, stress
testing involves pea* volumes of data encountered over a short span of time. /ou may want to
perform stress tests when particular stress situations are evident in an application and ma*e it
vulnerable to these occasional situations.
Enterprise Testing %"ystems'
)imed at proving the correct implementation of a required function at an $nterprise level
%(orporation and (ustomer' where the entire hardware/software chain is tested and verifed.
&latform Testing %"ystems'
5erifying that the software, including operating systems and platforms are compatible and
function together. 0latform testing covers things such as new release of operating systems,
platform upgrades, new releases of 5., upgrades to application software, communication line
testing, etc.
Interface Testing %"ystems'
The process of testing that all applications eternal to your system, that receive input from your
system, can process that input correctly and that you can process input provided by eternal
applications to your system.

&arallel Testing %"ystems'
The process of running the -perational "ystem and the new or changed system %in a test or
operational environment' with identical input, and comparing operational output to test output.
Release Date: 03/11/02 Page 2 of 3 Version 1.0
Installation Testing %)cceptance'
$nsures that the total system, including batch and online modules, can be successfully installed
and eecuted in the operational environment. Testing could include& -perational, 1ecovery,
"ecurity, or 0ilot Testing.
Release Date: 03/11/02 Page 3 of 3 Version 1.0