In the last post, we’ve got the information mainly about Static Testing. We’ve also compared the Static and Dynamic Testing and we’ve seen how are the phases of Review.
In this post we will get the information about the Review Types.
First of all, reviews can be executed for various purposes, one of the main objectives is to uncover defects. What’s more, a single work product can be the subject of more than one type of review.
We have four main types of review (ISTQB FL). We will describe all four below.
Informal review
An informal review is a review whose main purpose is detecting potential defects. More possible additional purposes can be generating new ideas or solutions, or quickly solving minor problems. It’s not based on formal processes, which means we can document it or not. This type of review may not involve a review meeting and a colleague of the author or more people may perform it. We can document the results but it’s not required. We can use the checklists optionally. Informal review varies in usefulness depending on the reviewers. We use this review type mainly in an Agile environment.
The examples of informal review:
- buddy check
- pair review
Walkthrough
The walkthrough is the review where are a lot of main purposes. It can be finding defects, improving the software product, considering alternative implementations, or evaluating conformance to standards and specifications. More possible additional purposes can be exchanging ideas about techniques or style variations, training of participants, or achieving consensus. While we didn’t need to prepare ourselves for the informal review, we can prepare ourselves for the walkthrough. The author of the work product leads the review meeting and Scriber is mandatory in the meeting as well. In this review type, we can use the checklists optionally as well as we could in the informal review. Walkthroughs may take the form of scenarios, dry runs, or simulations. We can produce the potential defect logs and review reports. Moreover, the walkthroughs may vary in practice from quite informal to very formal.
Technical Review
Technical review is the review where are a lot of main purposes similar to in walkthrough. It can be gaining consensus or detecting potential defects. More possible additional purposes can be evaluating quality and building confidence in the work product, generating new ideas, motivating and enabling authors to improve future work products, or considering alternative implementations. Reviewers should be technical peers of the author and technical experts in the same or other disciplines. Moreover, we have to prepare ourselves before the review. We can execute the review meeting optionally and this meeting should be led by a trained facilitator (typically not the author). Scriber is mandatory and it should be not an author as well. We can use the checklists optionally. We can produce the potential defect logs and review reports.
Inspection
The last type is the Inspection, which is the review where are a lot of main purposes similar to in walkthrough. It can be detecting potential defects, evaluating quality, and building confidence in the work product, preventing future similar defects through author learning and root cause analysis. More possible additional purposes can be motivating and enabling authors to improve future work products and the software development process, achieving consensus, for instance. It’s a formally documented process output, based on rules and checklists, which follow a defined process. We need to prepare ourselves before the inspection. Reviewers are either peer of the author or experts in other disciplines that are relevant to the work product. During this review, we’re using the defined roles.
Let’s say something about the roles in formal review.
An author is a person who creates the work product under review and fixes defects in the work product under review (if necessary).
Management is responsible for review planning, decides on the execution of reviews. For instance assigns staff, budget, and time monitors ongoing cost-effectiveness and executes control decisions in the event of inadequate outcomes.
A facilitator (or called moderator) is a person who ensures effective running of review meetings (when held), What more, mediates, if necessary, between the various points of view. Moreover, is often the person upon whom the success of the review depends.
The review leader takes overall responsibility for the review and decides who will be involved and organizes when and where it will take place.
Reviewers are the people who may be subject matter experts, persons working on the project, stakeholders with an interest in the work product, and/or individuals with specific technical or business backgrounds and identify potential defects in the work product under review. They can also represent different perspectives (e.g., tester, developer, user, operator, business analyst, usability expert, etc.).
Scribe (or recorder) collates potential defects found during the individual review activity and records new potential defects, open points, and decisions from the review meeting (when held).
Now we know what kind of review types we have (main types) and we’ve described ourselves the roles in the formal review.
I hope you enjoyed reading this article.
The next post will arrive soon 🙂
The part content of this post was based on ISTQB FL Syllabus (v. 2018).
Graphics with hyperlinks used in this post have a different source, the full URL included in hyperlinks.
