go back to the blog

Practical Risk-Based Testing by Erik Van Veenendaal

  • 26/04/2011
  • no comments
  • Posted by EuroSTAR

Often the activities prior to test execution are delayed. This means testing has to be done under severe pressure. It would be unthinkable to quit the job, to delay delivery or to test badly. The real answer is a differentiated test approach in order to do the best possible job with limited resources. Which parts of the systems require most attention? There is no unique answer, and decisions about what to test have to be risk-based. There is a relationship between the resources used in testing and the cost of finding defects after testing. There are possibilities for a stepwise release. The general approach is to test some important functions that hopefully can be released, while delaying others. At system level, one probably has to test first what is most important in the application. This can be determined by looking at visibility of functions, at frequency of use and at the possible cost of failure. Secondly, one has to test where one may find most defects. This can be determined by identifying defect prone areas in the product. Project history gives some indication, and product measures give more. Using both, one finds a list of areas to test more and those to test less. After test execution has started and one has found some defects, one may analyse these in order to focus testing even more and tune the test approach. The idea is that defects clump together in defect prone areas, and that defects are a symptom of a particular trouble the developers had. Thus, a defect leads to the conclusion that there are more defects nearby, and that there are more defects of the same kind. Thus, during the latter part of test execution, one should focus on areas where defects have been found, and one should generate more tests aimed at the type of defect detected before.

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery