Types of Testing
Development-Level Testing
Unit Testing: The testing of each
individual module that comprises the system. Testing checks only
the module in question and is based on knowledge of the coding
included in the module. Inputs will be in the form expected by
the module and outputs will be accepted in the form produced by
the module.
 |
Risk if not completed Defects
made at the unit level may not be caught until much later in
the testing cycle, leading to delays and extra costs.
|
Initial Testing
Configuration Testing:
Checks the operation of the program under various
software and hardware configurations that might exist or be
implemented at customer sites.
 |
Risk if not completed A
prospective client may be unable to run the provided
system correctly at their site.
|
Compatibility / Conversion Testing: Confirms that the
program is compatible with any co-resident programs and that the
data output by the program is in the correct format to be used
as input for a succeeding program or programs. Conversion
testing confirms that any required or expected data conversions
occur without loss of data or information.
 |
Risk if not completed The
output from the program may not be in a format acceptable
to a program with which it is required to interface.
Data may not be converted properly from one release to
the next. |
Installability Testing: Confirms that the program can
be installed in the expected environment without problems and
without affecting any other programs or data on the machine.
 |
Risk if not completed After
all other testing is completed, the system cannot be
installed in the final environments.
|
Ongoing Testing
Functionality Testing:
Confirms that the functions listed in the specifications operate
properly in the software, in all identified environments.
 |
Risk if not completed The
system may not operate as required. |
Facility Testing: Confirms that all the
documented facilities are implemented in the system to be
shipped. Facilities include items that are not direct
functionality but are included in the product.
 |
Risk if not completed The
system may not contain all the facilities expected.
|
Security Testing:
Confirms that the program can restrict access to authorized
personnel and that the authorized personnel can access the
functions available to their security level.
 |
Risk if not completed
Personnel without sufficient security clearance may be
able to
execute inappropriate functions and processes. |
Performance Testing
Volume Testing:
Confirms that any values that may become large over time (such
as accumulated counts, logs, and data files) can be accommodated
by the program and will not cause the program to stop working or
degrade its operation in any manner.
 |
Risk if not completed It may
not be possible to operate the complete system with all
data in place if the volume of expected records is not
checked during testing and verified to work correctly
and completely. |
Stress Testing: Confirms that the program continues to
operate when subjected to stress (that is, during a short, sharp,
peak of intensive activity).
 |
Risk if not completed Users
may find the system response becomes non-existent or
unacceptably slow under some conditions if the system is
not confirmed to operate properly under conditions of
stress. |
Load Testing: Confirms that the program operates
without memory loss or degradation of performance for several
days without being shut down.
 |
Risk if not completed
When
the system is placed under load to complete a number of
transactions in a short time, it may not respond
appropriately. |
Performance Testing:
Checks the programs speed. It checks both speed of response to
the user and speed of execution of any underlying batch
programs, under conditions of both normal and stress usage.
 |
Risk if not completed
System performance may be too slow to meet your
requirements, and may impede your users from successful
completion of functions. |
Storage Testing: Checks that the program stores data
files in the correct directories and that it reserves sufficient
space to prevent unexpected termination resulting from lack of
space.
Note: This is external storage as opposed to
internal storage.
 |
Risk if not completed
The
system may not be able to store the expected volume of records, and
this may cause unexpected and unknown errors. |
Post-Functional Testing
Usability Testing:
Confirms that the program conforms to requirements standards and
that the interface is accessed and manipulated in a
user-friendly fashion.
 |
Risk if not completed Screens and
functions may be modified through the requirements and
development cycle and lose the usability originally
built in. |
Reliability Testing:
Confirms that the program operates and provides accurate and
consistent results under normal usage.
 |
Risk if not completed The
system may provide anomalous results under different
conditions. Results will not be the same and cannot be
trusted. |
Recovery Testing:
Confirms that the program recovers from expected or unexpected
events without loss of data or functionality. Events can include
shortage of disk space, unexpected loss of communication, or
power out conditions.
 |
Risk if not completed The
system may lose data in unexpected and unknown ways if
recovery from unexpected errors is not checked. |
Post-Installation Testing
Serviceability:
Confirms the ability of trained personnel to service the program
and make required changes without affecting the ongoing use of
the program or any existing data. An example of servicing a
program might occur when there has been an unexpected crash and
development is required to recover data. Serviceability testing
confirms the ability to implement that recovery.
 |
Risk if not completed It may
not be possible to implement changes and fixes to the
system as required if the system is not checked and
confirmed to be serviceable. |
Completion Testing
Documentation:
Reviews all pieces of documentation for consistency, adherence
to standards, and accuracy.
 |
Risk if not completed
Documentation may not reflect the requirements of the
user and the nature of the system. |
Procedure:
Confirms that all documented procedures are accurate and can be
implemented as they are written.
 |
Risk if not completed
Provided procedures might not operate as expected or as
documented unless tested on the final system prior to
implementation. |
|