The various types and levels
of testing can be be define defined as Unit testing,
Integration testing, Systems testing, Requirements testing,
Beta testing, Stress testing, Regression testing,
Reliability testing, Performance testing and Usability
testing. These test types are are explained below:
This is testing of compiled program code at the lowest level
and is source code that does not include any called
subroutines or functions. Fundamentally, every source
statement is executed at least once during testing. The
tests are performed to find unit execution problems, which
represent the second most frequent type of bug.
Here the testing of interfaces between otherwise correct
components and modules is covered to ensure compatibility.
Integration bugs are just behind Unit bugs in frequency
although for Objected Oriented software, they may be more
Testing an entire software system end to end to discover any
common system bugs such as loss of resource, synchronization
and timing problems, multi-user sharing problems etc. After
fixing the low level bugs any system bugs can be addressed.
These will cover end to end tests from the User perspective
to verify operability of each feature. It may not be good to
presume that ‘user’ just means ‘end-user’. In typical
software, only 10% - 15% of the code directly concerns
things immediately seen by the end user. The remaining 85%
concerns infrastructure items such as resource management,
protocols, databases and files that the user does not know
about or want to know about.
Beta testing is usually done by representative users,
typically in the final stages of testing prior to official
release. A small representative sample, normally under 1%,
of an installed user base can be an effective way to
discover any latent configuration sensitivity and
performance bugs not previously found.
It involves subjecting a software system to an unreasonable
load while denying it the resources needed to process the
load. This can be one of the most economical ways to find
system bugs. Proper stress testing is useful in finding
synchronization and timing bugs, interlock problems,
priority problems, resource loss bugs and general abuse of
application program interfaces.
This is more specifically Equivalency testing; i.e.
re-running a suite of tests to assure that the current
version behaves identically to the previous version except
in areas where changes have been applied.
This will determine the expected failure rate of software
under a statistically specified user load or operational
profile. Reliability testing can give an effective method to
determine when enough testing has been completed to warrant
migration to production.
This is the testing to determine the expected processing
delay as a function of the applied load (and to determine
the resource utilization under load). This testing may
involve determination of the maximum simultaneous users or
transactions that a system can sustain. Simple tests may be
feasible. For example, inspection of memory being used or
simple batch process job timings.
This involves testing the human / machine interface
including the screen menu layouts, help features,
instruction manuals and icon style and placement in order to
confirm that such things are well thought out and the system
can be learnt and used with a minimum of effort. This type
of testing should commence during early development stages
otherwise in may be too late to make any substantive