Database Reference
In-Depth Information
that programmers don't like to do this. Another reason is that it's very
time consuming.
You can consider the unit testing a programmer does at his or her own
desk, meaning the testing of a unit of work (a program). When several pro-
grams have to interact together, another type of test that you might want
to perform is integrating testing . This is a test to determine if the separate
parts of the system work well together. For example, let's say Program 1
creates a file that contains a student file, and Program 2 then processes
that student file. If Program 1 makes a mistake and creates the student file
incorrectly, then Program 2 will not work.
A system test tests the complete system. All of the inputs are checked; all
of the outputs are checked; and everything in between is checked. If there
is another existing system, a parallel test is done. Parallel is a good term
for this, because to do this you must run both system in tandem and then
check the results of both for similarities and differences.
Finally, acceptance testing is done. This means that you run a test and
the end user either agrees or disagrees with the test and approves or disap-
proves it.
In any case, testing is a lot of work. Many people are involved, including
the end users and, usually, a quality assurance (QA) department. QA folks
spend all of their time writing testing scripts (i.e., a list of things to test for)
and then running those scripts. If they find an error, they send a report to
the programmer, who then fixes it.
QA usually uses testing tools to assist with this massive job. These
tools assist with the creation of scripts and then automatically runs
those scripts. This is especially helpful when doing stress testing—test-
ing to see how well the system works when many people are using it at
the same time.
Testing is usually not performed in a vacuum. An analyst or man-
ager prepares a test plan that details exactly what must be tested and by
whom. The test plan contains the testing schedule as well as the intricate
details on what must be tested. These detailed plans are called test cases
and form the basis for the test scripts that are used by the programmer or
the QA staff member, usually in conjunction with a testing tool.
A sample test case that would appear in a test plan is presented here.
This would be turned into a script for use by the testers.
Search WWH ::




Custom Search