Flexibility in determining testing requirements is allowed in order to avoid setting requirements that could be inappropriate for many situations. Further consider that example problems are included in the software documentation that demonstrate the ability to correctly perform some, but not all, the analysis methods that are incorporated. If the software will be used to perform only the methods that were tested, then no additional documented testing is required. While it is expected that a user would run one or more of the supplied test problems to make sure that the software has been installed properly, it would not be necessary to save those test results in the project files. If one of the untested methods will be used, however, then a documented test should be made to gain confidence that the method has been implemented as described.
Undocumented testing is any other testing.
As already mentioned, previously documented tests are typically rerun to gain confidence that a program is installed properly. It is also customary to perform some undocumented testing of programs that do not perform significant analysis. It is usually fairly easy to make some tests to see that the appropriate output is produced in a variety of situations. In summary, although one cannot prove that software is error free, testing provides confidence that the software performs analysis as stated in the documentation. The policy for testing is intentionally kept flexible with the recognition that uncertainty is better than making a rigid policy that is likely to be inappropriate in many situations.