Information Technology Reference
In-Depth Information
Types of Testing
Any application under development will have certain engineering areas
or features that are more important than others. These factors are critical
to the application's success and depend on the nature of the application
as well as its specific implementation. For example, in a CRM (customer
relationship management) application, the ease of user interaction is given
more weight because the productivity of hundreds of users is key to the
success of the application. In an E-commerce site, security might be more
important, while in a bank reconciliation application, data integrity is
crucial. The testing strategy for any application being developed is often
determined by the relative importance of such factors.
After selecting the critical success factors, one should develop a testing
strategy that places more importance and resources on these factors. To
give an example, in the case of the bank reconciliation system, more time
should be devoted to debugging and testing date-related modules, while
less time should be devoted to the user interface screens. This may lead
to the realization that the developers and the testers do not have adequate
tools to create the required data, or that one may need a database
administrator attached to this project to support the intense data manage-
ment requirements.
It is rarely feasible to do all the kinds of testing that one would like
to perform. As such, one should be careful in the type of testing selected.
There should be a systematic process, backed by a comprehensive test
plan. Random testing is inadequate. The testing process works best when
done systematically. This also provides an assurance about the reliability
of the results or conclusions being drawn. Simultaneously, it enables one
to compare results from various test cycles, thereby determining whether
the situation is improving, and to what extent.
Testing should always involve a premise, that is, testing for the cor-
rectness of a predetermined “something.” There should be a hypothesis,
based on behavior symptoms displayed by the software, that can be shown
to be true or false, accepted or rejected. This approach is implicit in most
test plans. For example, first, implicitly or explicitly, state a premise: “a
date field should accept only valid date values.” Then set up a hypothesis:
“this date field accepts a Feb 30 date.” Then prove or disprove that
hypothesis by entering that date, and seeing whether or not it is rejected.
The various types of testing are discussed below.
Systems Testing
In any system, the behavior of lower-level components is not a sufficient
predictor of system behavior; certain behaviors can emerge at a higher
