Testing by the developer is a key part of a full testing strategy. Independent testing is also important but is outside the scope of this book.
Writing test cases before the code takes the same amount of time and effort as writing the test cases after the code, but it shortens defect-detection-debug-correction cycles.
Even considering the numerous kinds of testing available, testing is only one part of a good software-quality program. High-quality development methods, including minimizing defects in requirements and design, are at least as important. Collaborative development practices are also at least as effective at detecting errors as testing, and these practices detect different kinds of errors.
You can generate many test cases deterministically by using basis testing, dataflow analysis, boundary analysis, classes of bad data, and classes of good data. You can generate additional test cases with error guessing.
Errors tend to cluster in a few error-prone classes and routines. Find that errorprone code, redesign it, and rewrite it.
Test data tends to have a higher error density than the code being tested. Because hunting for such errors wastes time without improving the code, testdata errors are more aggravating than programming errors. Avoid them by developing your tests as carefully as your code.
Automated testing is useful in general and is essential for regression testing.
In the long run, the best way to improve your testing process is to make it regular, measure it, and use what you learn to improve it.
