Information Technology Reference
In-Depth Information
Exceptional cases
3 Essential tests
Figure 12.3
Never forget to test these.
Late design additions
. Design changes brought in after the system
has already been in development are more likely to have problems.
In all likelihood, problems will not appear uniformly throughout the
source code. There will be areas where complex business logic is imple-
mented — the probability of a defect occurring will naturally be higher.
Defects repeat and often reflect individual developer's coding habits, and
their blind spots. QA and Engineering personnel should work together to
factor such occurrences into their test prioritization strategy.
In addition, there are three tests that are essential (Figure 12.3):
Exceptional cases
: things in the requirement specifications that are
not supposed to happen in the system — which most likely have
been overlooked by the developer.
Boundary conditions:
array limits, negative or null values,
extremely large values ( e.g., percentages value greater than 100).
Input conditions
: wide range of inputs because one can never
predict what users (or interfacing systems) will enter, knowingly
or unknowingly.
Another aspect of testing is
periodicity
. Just as a person goes for regular
medical checkups, one should also establish a process to examine the
health of software periodically through diagnostic tests, even when the
system looks and behaves properly and the customers are not complaining.
