Goals of testing

From dis-Emi-A

Testing can mean many different things depending on who is doing it, and where in a process it is being performed. To a programmer testing is usually the construction of automated tests to check for correctness and prevent regression. To a user testing can be the evaluation of the new version of a software. To a consultant testing could mean the verification that a configuration is valid. To a system administrator testing could mean measuring the performance of a new installation.

To a quality testing team, testing may include all of that, but primarily, testing is simply a status check. Whereas a programmer, or administrator, need to correct problems identified by tests, a dedicated tester does not take part in such resolution. Testing is their work, and it is this work we are interested in here.

Testing Goals

Verification: Testing provides a status report of the actual product in comparison to requirements (written and implicit). At its simplest this is a pass/fail listing of product features; at detail it includes confidence numbers and expectations of defect rates throughout the software.
Priority Coverage: Not everything can be tested, not even a significant subset of everything can be tested ^[1], therefore testing needs to assign effort reasonably and prioritize thouroughly.
Traceable: Exactly what was tested, and how it was tested, are needed as part of an ongoing development process. In many environments such proof of activities are required as part of a certification effort, or simply as a means to eliminate duplicate testing effort.
Unbiased: Tests must balance the written requirements, real-world technical limitations, and user expectations. Bias in a tester invariably leads to a bias in coverage.
Deterministic: The discovery of issues should not be random, the coverage criteria should expose all defects of a decided nature and priority. Furthermore, later surfacing defects should be identifiable as to which branch in the coverage it would have occured, and can expose a definite cost in detecting such defects in future testing.

Testing Non-Goals

Quality Assurance: Testing is but one part in a full quality assurance program. Substituting testing for QA is simply not an option.
Antagonistic or blame finding: Testing is simply a step in a process to identify problems. Using it as a tool to lay blame creates tension between teams and leads to undue stress on the testing team.
Bug hunting: Testing is verification, and while issues naturally arise, that is not the primary goal
Guarantee / Approval: Testing simply produces a status report, how the overall development process interprets that is another question. The test process itself does not provide a guarantee of the product, nor a stamp of approval from the testing tream.
Infallible: Since not everything can be tested, it is not realistic to expect that all defects can be found by testing. Only those as covered within an agreed upon test plan can be expected to be identified.