Information Technology Reference
In-Depth Information
On the topic of dictionary completeness, it should be noted that passing
a spell-check does not mean that there are no errors. How many times
have we typed the word “sue” instead of “use” in a sentence and got
passing grades because both words are “in the dictionary?”
In the earlier example, because we have added only a few sentences,
it is tempting to visually inspect the new sentences oneself. Would this
be called regression testing? By one definition, it is not because the first
test was done using the spell-checker, a kind of automated testing with
embedded logic. By not using the automated testing, one risks missing
an error condition as specified in the “test plan.” Fortunately, spell-checkers
do allow one to spell-check only the two new sentences. That would be
acceptable for this example because the addition of two sentences is
unlikely to have “side effects” in the rest of the document. However, in
software, the addition of two statements is likely to have side effects,
which complicate the scope of regression testing. Many a regression test
is skipped or shortened because the tester or developer is very sure that
“nothing else is affected.”
Regression Problems
Very often, defects follow a set pattern. We can then use these to create
anti-patterns, catalog them, and use them to guard against future defects.
Some of these anti-patterns can be automated with tool support. Some
integrated development environments (IDEs) used by programmers also
have facilities to invoke such checks in the background while the devel-
oper creates code. These checks and patterns should be introduced as a
step in the development and testing life cycles. They can be used as
guidance for doing better reviews and become “watch points.” Regression
testing is another way of building watch points into the software devel-
opment process.
Scope of Testing
How much should one test? The theoretical answer is that we should test
everything; however, this is not feasible because the space of inputs, and
corresponding possible logic conditions, is large enough. It is because of
this that program correctness is considered in the NP-Complete class of
problems. Furthermore, proving the existence of correct behavior in a
piece of software is easier than proving the nonexistence of incorrect
behavior. That is why we must rely on testing to get us to a state where
we feel comfortable in releasing the software for use.
