R. Clayton (rclayton@monmouth.edu)
Tue, 28 Mar 2000 16:28:31 -0500 (EST)
As testers, are we supposed to locate where the error occurs in the code
or are we supposed to just mention that an error occurs or do we do
both?
The purist's answer is that testers just drive the system to faulty behavior,
they do not determine why the system's faulty or how to fix the system. There
are at least two justifications for this. The first is that good testing is a
difficult thing to do, and anything you can do to remove distractions and keep
the testers focused on testing is good. The second reason is that debugging
and maintenance is also hard to do well, requiring, among other things, an
intimate knowledge of the system's design and implementation. It would be an
almost impossible burden for the testers if they also had to do debugging and
maintenance too.
As a practical matter, there is some blending among testing, debugging, and
maintenance. For example, implementers usually do the first-cut unit tests on
the units they produce. However, too much blending and you start to raise
psychological issues. For example, I suspect if testers had to do debugging,
you would begin to find, over time, that the code would be magically fixing
itself as test cases began revealing fewer and fewer instances of faulty
behavior.
In any event, no matter how you blend testing, debugging, and maintenance,
testers must always record faults that have occurred during tests. This
information is crucial for communicating with the debuggers, for performing
regression tests, and for managing the software development process.
With respect to your project, I want you to do just testing; no debugging or
maintenance.
This archive was generated by hypermail 2.0b3 on Thu Mar 30 2000 - 20:50:05 EST