5. Review Types
As any event where someone needs to go through a document with another one, there could be multiple reasons why you need to go through a document with another one. The objectives of any review could be finding defects, gaining understanding, educating participants such as testers and new team members, or discussing and deciding by consensus. The focus of any review depends on the agreed objectives of the review. But despite what type of review, finding defects is always welcome in any type of reviews.
You won’t find someone pointing a defect to you in a document and your reply would be no. This meeting is only to educate you about this document, so you are not allowed to find a defect in this document. So finding defects is always a purpose for any review type. There are four types of reviews vary in their formality, starting from the lowest to the highest formal review type we have informal walkthrough, technical review and inspection.
There are different factors that help to decide the review type. Those are project based factors that affect the type of review for example, the needs of the project, available resources, product type and risks, business domain, company culture and other selection criteria. Reviews can be classified according to various attributes. The following lists the four most common types of reviews and their associated attributes.
Questions in the exam are usually about differentiating between the different review types, so we will try to pinpoint some keywords to highlight the few type characteristics. First, informal Review informal review also known as body check pairing peer review the main purpose is to quickly find effects and an inexpensive way to achieve some limited benefit.
Possible additional purposes generating new ideas or solutions quickly solving minor problems. The least formal review type, where there is no formal process to answer, may not involve a review meeting and may be performed by a colleague of the author body check or by more people. Findings in the review are not usually documented. Informal review varies in usefulness depending on the reviewers. Use of checklists is optional and last, very commonly used in agile development as an example of the informal review is pair programming, a technique introduced by the Agile Extreme programming methodology where two programmers work together to write the same code. So one programmer instantly reviews the code of the other programmer.
The keyword here is no process and quick. Second is walkthrough, where the author has something to explain or show in his document to the participants. So the main purpose here is for the participants to learn something from the document or gain more understanding about the content of the document. Also, workshop can be used to find effects in the document, improve the software product, consider alternative implementations, evaluate confirmations to standards and specifications possible additional purposes exchanging ideas about techniques of style variations, training of participants and achieving consensus in this type of review, the meeting is led by the author.
Review sessions are openended and may vary in practice from quite informal to very formal. Appointment of a scribe who is not the author is mandatory. Preparation by reviewers before the walkthrough meeting is optional. Use of checklists is optional. When you walk through a work product, it may take the form of scenarios, dry runs or simulations. We will talk about scenarios and dry runs in another video. Defect logs and review reports may be produced, so they are also optional.
Keywords here lived by the author main purpose learning and gaining understanding and most of the review process activities are optional. Third Technical Review A technical review is a discussion meeting that focuses on achieving consensus about the technical content of a document. Finding defects is a blast as usual. Possible further purposes Evaluating quality and building confidence in the worker product, generating new ideas Motivating and enabling authors to improve future worker products. Considering alternative implementations reviewers are usually experts in their field and can be technical peers of the author. Most of the review process activities are executed. Individual preparation before the review meeting is required. The review meeting is optional, ideally led by a trained Facilitator. Typically not the author.
Scribe is mandatorily, ideally also not the author. User checklists is optional. Potential defect logs and review reports are typically produced. Keywords here led by a trained motivator. Purpose is discussion, gaining consensus and taking decisions and evaluation of alternatives, and most of the activities in the view process are executed. Last and most formal is inspection. Inspection Main purposes detecting potential defects, evaluating quality and building confidence in the worker product preventing future similar defects through author learning and root cause analysis. Possible further purposes Motivating and enabling authors to improve future work products and the software development process and achieving consensus. An inspection follows a defined process with formally documented outputs based on rules and checklists.
All the rules mentioned in the various video are mandatory and may include a dedicated reader who reads the worker product aloud during the review meeting. Note that reader was not mentioned in the rules. It’s also mentioned here in the inspection, so it may include a dedicated reader. Individual preparation before the view meeting is required. The viewers are usually peers of the author and should be experts in disciplines that are relevant to the worker product. Specified entry and exit criteria are used. Scribe is mandatory. The view meeting is led by a trained facilitator, again not the author. The author cannot act as the review leader, reader, or scribe. Potential defect logs and review reports are reduced. Metrics are collected and used to improve the entire software development process, including the inspection process. Keywords here Led by a trained Motivator the main purpose is finding bugs and all the activities in the review process are executed.
In reality, there’s a fine line between the view types often get blurred and what is seen as a technical review in one company may be seen as an inspection in another. The key for each company is to agree on the objectives and benefits of the reviews that they plan to carry out. Also, a single worker product may be subject to many different review types. For example, an informal review may be carried out before the document is subjected to a technical review or debating. A technical review on inspection may take place before a walkthrough with the customer. The types of reviews described can be done as peer reviews, done by colleagues at the same or a similar approximate organization level. The types of defects found in a review vary depending mainly on the local product being reviewed.
6. Applying Review Techniques
As I have said before, it’s a skill to eat a document and find effects in it. I see it as a skill like the movie critics. Many might go to a movie and like it, but critics find it very bad. Movie critics have trained eyes to find effects that others might not notice well. In this video, we will learn how to enhance this skill by learning a number of techniques that people use that you can apply during the individual review or individual preparation activity to uncover defects. These techniques can be used across the review types described before. The effectiveness of the techniques may differ depending on the type of review used. And as I said, it’s a skill, so it needs a practice to master those techniques. We will talk about five techniques ad hoc, a checklist based scenario, and dry runs. Rule based and prospective based. Ad hoc usually means no planning or little preparation. In an ad hoc review, reviewers are provided with little or no guidance on how this task should be performed.
Reviewers often read the worker product sequentially, identifying and documenting issues as they encounter them. This technique is highly dependent on reviewer skills and experience and may lead to many duplicate issues being reported by different reviewers. A Checklist Based we will talk about the checklist testing in detail in future videos. But for now, imagine if I give you a list of questions and asking you to answer them according to the document or test object you have at hand. This is simply checklist based testing. It’s a systematic technique. Reviewers detect issues based on checklists that are distributed at review initiation by the Facilitator.
They just answer the questions according to their point of view. A view checklist consists of a set of questions based on potential defects which may be derived from experience. Checklists should be specific to the type of vocal product under review and should be maintained regularly to cover issue types missed in previous reviews. Questions like Is the section nonfunctional requirements exist? Do we have a UML diagram for every use case? Does every function in the source code have a detailed comment about its purpose? The main advantage of the checklistbased technique is a systematic coverage of typical defect types.
Care should be taken not to simply follow the checklist in individual reviewing, but also to look for defects outside the checklist. Next is scenarios. And do I runs? In a scenario based review, reviewers are provided with structured guidelines on how to read through the Walker product. These scenarios provide reviewers with better guidelines on how to identify specific defect types than sample a checklist’s entries. A dry run is a testing technique where you try to mimic real life situations going as long as possible. For example, an aerospace company may conduct a dry run test of a jet’s new pilot ejection seat while the jet is parked on the ground rather than while it’s in flight. A scenario based approach supports reviewers in performing dry runs on the worker product based on the expected usage of the worker product. If the worker product is documented in a suitable format, such as use cases, role based, consider software like Microsoft Word.
You may consider potential users to this software like a student, a secretary, and a publishing company. Now I want you to imagine how each one of those users will use the software. A student wants everything to work using shortcuts and toolbar icons. A secretary is a speed typist. She wants only to use the keyboard to finish any task. A publishing company doesn’t mind going through detailed dialogues to set up the printing process very accurately. This is role based testing in which the reviewers evaluate the local product from the perspective of individual stakeholder roles.
Typical roles include specific end user types, like I mentioned, experienced, inexperienced, senior, child, and so on, and specific roles in the organization user, administrator, system administrator, performance tester, and so on. Last is perspective based technique. I think of perspective based reading as a mix of both rolebased and check based and scenario based techniques. This technique acknowledges that there are multiple consumers of the document to be used during the requirement development phase. PBR, or perspective based reading offers each of the reviewers a viewpoint’s or perspective specific to each type of consumer, similar to rolebased review. But here typical consumers or stakeholder viewpoints include end user, marketing, designer, tester, or operation.
The technique instructs the reviewers on precisely what to search for, thus enabling them to find more defects in less time. From each of these perspectives, the inspector is advised to apply a scenario based approach to reading a document. Each scenario consists of a set of questions and activities that guide the inspection process by relating the requirements to a regular work practices of a specific stakeholder. What does this mean? It means that perspective based reading also requires the reviewers to attempt to use the worker product under review to generate the product they would drive from it.
For example, a tester would attempt to generate draft acceptance tests if performing a perspective based reading on a requirement specification to see if all necessary information was included. Further, in perspective based reading, checklists are expected to be used. Using different stakeholder viewpoints leads to more dips in individual reviewing with less duplication of issues across reviewers. Empirical studies or statistics or experience have shown that perspective based reading to be the most effective general technique for reviewing requirements and technical worker products. A key success factor is including and waiting different stakeholder viewpoints appropriately based on.
7. Success Factors for Reviews
In order to have a successful review, the appropriate type of review and the techniques used must be considered. In addition, there are plenty of other factors that will affect the outcome of the review. We can categorize those factors to organizational success factors and peoplerelated success factors. Organizational success factors for reviews include each review has clear objectives defined during review planning and used as measurable exit criteria. Review types are applied which are suitable to achieve the objectives and are above it to the type and level of software. Worker products and participants.
Any review techniques used, such as a checklist based or role based reviewing, are suitable for effective defect identification in the worker product to be reviewed. Any checklists used should address the main risks and are up to date. Large documents are written and reviewed in a small chance so that quality control is exercised. By providing authors early and frequent feedback on defects, participants have adequate time to prepare. Reviews are scheduled with adequate notice. Management supports the review process, for example, by incorporating adequate time for review activities in project schedules. People related success factors for reviews include the right people are involved with to meet the review objectives. For example, people with different skill sets or perspectives who may use the document as a work input testers are seen as valued reviewers who contribute to the review and learn about the local product, which enables them to prepare more effective tests and to prepare those tests earlier. Participants dedicate adequate time and attention to detail. Reviews are conducted on small chunks so that reviewers don’t lose concentration during individual review and or review meeting. When held, defects found are acknowledged, abbreviated and handled.
Objectively the meeting is well managed so the participants consider it a valuable use of their time. The review is conducted in an atmosphere of trust. Everyone knows that the main objective is to increase the quality of the document under review. The outcome will not be used for the evaluation of the participants. I have seen companies that calculate the monthly bonus depending on the number of bugs. Bare Developer this is so unrealistic and unfair. Participants avoid body language and behaviors that might indicate boredom, irritation or hostility to other participants happens adequate training is provided, especially for more formal review types such as inspections. A culture of learning and process improvement is promoted. We should learn from our mistakes and we should use the metrics collected to improve the overall software process.
