Test effort
When testing effort applies the effort (cost) which is obtained for testing. The testing effort is one of the so-called quality costs of the product to be tested. Pole, Koomen, Spillner include in the cost of testing to the expense of preventive measures, ie to the costs for avoiding errors. These also include the cost of quality in software development (see "static testing " ) a. Likewise in particular include the active tests performed ( = " dynamic test modes") - from the perspective of the project purpose " go-live " - to avoid errors.
This preventive faces after the expenditure for reactive measures, the cost of error correction. In a narrower sense, they do not count towards testing effort, but the effort for the implementation. Nevertheless, they are, if they occur during testing, often counted for testing effort. This includes costs and damages that may occur ( through undetected error ) only after going live. They can act and even endanger the existence of the company ( in dramatic cases ) and outside the organization ( customers, the environment, etc. ).
For this rule of thumb is " The later errors are discovered, the more elaborate the Remedy ," from which is derived the reverse also: "Quality must ( in the whole course of the project ) implemented, will not ' be tested '.
Factors that influence the test effort are: maturity of the development process, quality and testability of the test objects, test infrastructure, staff qualifications, quality objectives and the testing strategy.
This article describes the issue of " testing effort " substantially related to software testing.
Approaches to estimating test effort
To analyze all factors is difficult because most of the factors affecting each other. It can be used to estimate the following approaches: metric- based ( in English called: top-down estimation ) and expert-based ( in English: bottom -up estimation ) approaches.
The metric- based techniques (as controlling instruments ) are based on a formula and are usually given relative to development costs: these include, among others, the Function Point method (FPA ) and the test - point analysis (TPA ). The appropriate information (eg, cost per stage or per test object, deviation Plan / Actual, defects found, the number of required re-tests, etc.) are identified and shown to demonstrate the quality and efficiency of the testing process.
The expert-based techniques are based on detailed information and often involve experts. The following techniques including: work breakdown structure ( in English: Work Breakdown Structure ( WBS) ) and Wideband Delphi ( WBD ).
Testing effort from the literature
The test effort ( in software projects ), depending on the author between 20 % and 70 % of the total cost. Pole, Koomen and Spillner they quantify in 30 % to 40 % of the total budget. The spread is determined by project- specific circumstances.
If the test required for the individual phases of the testing process is considered, it is distributed differently: with approximately 40 % depending on the test specification, the test implementation are often involved. The rest would have to be estimated for the planning, evaluation and testing of financial statements.
According to the "Principles of Software Testing " ( ISTQB ), Principle 2, is fully testing is not possible ( *); because testing can indeed show the presence of errors, not their absence ( Principle 1) - (*) because all influencing factors, are virtually non testable in all possible combinations (except for trivial functions). Therefore, the testing activities must be strategically planned in order to choose the test intensity, thus the testing effort "appropriate". According to Juran, referenced in, the test effort should be so high that the total cost is ( test effort plus potential errors related costs) at the lowest possible level. As the chart shows schematically the test costs in relation to the expectable reduction of error correction costs ( from remaining errors) occur at too low test intensity disproportionately high error correction costs, at too high a test intensity ( the costs of which extend linearly ) too high.
After ISTQB the amount of testing effort should be such that the tests provide enough information to decide on the release ( the Software).