Introduction to Test
Concepts
The purposes of testing are:
- To verify the interaction between objects.
- To verify the proper integration of all components of the software.
- To verify that all requirements have been correctly implemented.
- To identify and ensure defects are addressed prior to the deployment of
the software.
In many organizations, software testing accounts for 30 to 50 percent of
software development costs. Yet most people believe that software is not well
tested before it is delivered. This contradiction is rooted in two clear facts.
First, testing software is enormously difficult. The different ways a given
program can behave are unquantifiable. Second, testing is typically done without
a clear methodology and without the required automation or tool support. While
the complexity of software makes complete testing an impossible goal, a
well-conceived methodology and use of state-of-the-art tools, can greatly
improve the productivity and effectiveness of the software testing.
For "safety-critical" systems where a failure can harm people (such
as air-traffic control, missile guidance, or medical delivery systems),
high-quality software is essential for the success of the system produced. For a
typical MIS system, this situation is not as painfully obvious, but the impact
of a defect can be very expensive.
Well-performed tests, initiated early in the software lifecycle, will
significantly lower the cost of completing and maintaining the software. It will
also greatly reduce the risks or liabilities associated with deploying poor
quality software, such as poor user productivity, data entry and calculation
errors, and unacceptable functional behavior. Nowadays, many MIS system are
"mission-critical", that is, companies cannot fulfill their functions
and experience massive losses when failures occur. For example: banks, or
transportation companies. Mission-critical systems must be tested using the same
rigorous approaches used for safety-critical systems.
The Test discipline is related to other disciplines.
- The Requirements discipline captures requirements in a
use-case model, which is one primary input for identifying what tests to
perform.
- The Analysis & Design discipline describes how to
develop a design; this is the other primary input for identifying what tests
to perform.
- The Implementation discipline produces builds of the
implementation model that are tested by the Test discipline . Within an
iteration there are several builds tested, first when the system is
integrated, and last to test the whole system.
- The Environment discipline develops and maintains
supporting artifacts that are used during test, such as the Test Guidelines.
- The Management discipline plans the project, and each
iteration (described in an Iteration Plan).
Copyright
© 1987 - 2001 Rational Software Corporation
| |

|