So, they do this in behalf of the project. The project manager is therefore responsible for the execution of a product risk analysis. Testers are interested in product risks. A disadvantage that people experience with performing a product risk analysis is that product risks are often abstract, while making test cases implies a very concrete and detailed level. Test cases cover very concrete things like boundary values, combinations of data, paths, statements etc.
These are other aspects than the ones we find with product risks. Many therefore have the feeling that along the way the relation between risks and the test cases gets lost. That is very serious. Designing test cases is indeed the essential link between the test strategy and thereby the product risks and the concrete test cases with which this test strategy is executed.
The derived test cases should be a substantiated elaboration of the test strategy: the agreed coverage on the agreed place. The solution is to ensure traceability when creating a test strategy from product risks, or when executing a product risk — where possible — performing a deepening process. In this deepening process a declaration should be made on risks on the level of coverage types.
Because of limited information it is usually not possible to directly link coverage types to requirements. As soon more information becomes available, such as functional specifications, the risks should be elaborated towards coverage types, by means of some intermediate steps.
As mentioned, there are several definitions of product risk. One formula is, according to Wikipedia :. Or in plain words: a product risk is the chance that the product fails in relation to the expected damage if this occurs. The Chance of failure is determined by the Chance of defects and the Frequency of use. The chance of defects is the chance that a product component contains a defect.
The presence of a defect in the product, however, does not mean that that defect will actually manifest itself in production. When the defect is in a part of the product that is never used, the product will not fail. The more often the product component with the defect is used — or, the higher the frequency of use — the greater the chance that the product will fail.
There is not one right way of performing a PRA, but in general you may want to follow these five steps:. We have already seen that requirements may be directly linked to product risks. There are more sources of input to identify product risks:. Search Search. What is Risk Based Testing? Guidelines for Software Testing. You may like these posts. Glad to announce e-learning school and online trainings. Model Based Testing.
What is Risk Mitigation or Risk Control? Risk Analysis attempts to identify all the risks and then quantify the severity of the risks. A threat, as we have seen, is a possible damaging event. If it occurs, it exploits a vulnerability in the security of a computer-based system. Items with higher risk values should be tested early and often. Items with lower risk value can be tested later, or not at all. It can also be used with defects.
When a test plan has been created, risks involved in testing the product are to be taken into consideration along with the possibility of their occurrence and the damage they may cause along with solutions, if any. A detailed study of this is called Risk Analysis.
0コメント