Effective evaluation
Mar10
The Testing of applications provides insight into the difference between current and required status of a test object [Koomen, 2006]. Testing belongs to the detecting means of a quality systems, like evaluation. However testing assesses finished products and evaluation assesses intermediate products. Compared to evaluation testing is an expensive quality measure. Already in the Eighties Boehm has shown that resolving errors in the beginning of the development process is cheaper than at the end. Not testing is always more expensive than testing, but through evaluating products such as functional requirements and design may be a quality measure which is cheaper than testing the resulting end products.
Evaluation is a simple but time-consuming task for a lot of people. Furthermore, people want to and can often spend insufficient time for the proper assessment of intermediate products. Thus, the result is that the potential positive impact of the property remains low key in practice. Evaluation has to be even more effective, this can be done with reading techniques! There are various reading techniques, namely:
- Ad-hoc Reading Technique;
- OORT, Object Oriented Reading Technique;
- DBR, Defect Based Reading;
- CBR, Checklist Based Reading, and
- PBR, Perspective Based Reading.
This is not a complete list, but these are the most important. Each technique has its own applications. In the following I tell a little bit on PBR.
Perspective Based Reading (PBR)
Perspective Based Reading is a reading technique that aims to find defects in intermediate products as early as possible, based on certain procedures. To the extent this doesn’t differ very from other reading techniques. But what are these procedures? Put simply, when evaluating there the context or perspective of the reviewer should be taken into account. The perspective of the reviewer determins what he/she is evaluating on in the intermediate. For example, a tester will look at a document from a test perspective, to check whether these requirements are good for the specification of test cases. Users verify that the intermediate product meet their expectations regarding completeness and functionality. Designers verify the document with the purpose that it contains sufficient detail to be properly and fully processed in functional designs. The aim is to deliver something physical what can be used in the follow-up processes. A tester can provide overall test cases and a user can provide the conversion for work instructions.
The assumption of PBR is that the merging of all individual prospects delivers a better analysis of the resulting document. On average, 58% of the total number of defects in a product are found by using PBR. But more importantly is that on average 56 minutes of reading is required to find a defect. If more experience is gained with PBR and processes to be adjusted, the speed of defects per page will rise even further.
Phases
For applying PBR in a good manner the technique has been phased. A moderator should hold on to these phases during the review session, is he/she wants it to be successfully completed. The following phases are known:
- planning;
- preparation;
- discussion;
- administration, and
- correction.
In the planning phase there should be determined what the perspectives are within the organization. Following this the focus of the reviewers should be determined. Also the following method of reviewing is determined. This should be transferred to the reviewers in advance.
In the preparation phase, the actual review is done from a certain perspective. Reviewers submit their findings in a review log and report it back to the moderator.
During the discussion phase, the findings are discussed with all reviewers, the author of the intermediate product and moderator, just as in a normal inspection. Subsequently, the author presents the records of the findings. Finally, the author processes the adjustments in the intermediate product.
Result
By using PBR, it is possible to be successful at finding defects at an early stage in the project. As a result that there will be fewer findings at a later stage in the project. Because we find errors early they can be solved cheaper and we will improve the chances of a better result with less risks. Because people with a particular perspective check the intermediate product, there will more defects and as a result created something to aid their own work. In addition, PBR finds more defects in less time.
Bibliography
[Koomen, 2006]
Koomen, T., Aalst, L. van der, Broekman, B, Vroon, M., TMap Next For result-driven testing, Tutein Nolthenius, ISBN 90-72194-79-9
[Basili, 1997]
Basili, VR, Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sørumgård, S., Zelkowitz, MV, The Empirical Investigation of Perspective-Based Reading, Empirical Software Engineering, 2, 1997