then let's discuss different types of reviews so there are three main review types what are those first one is walkthrough second is technical review and third one is inspection so let's discuss different types of reviews one by one so walkthrough is a step-by-step presentation of the document to establish common understanding and gather feedback about documents walk through is nothing but a step by step you are just in in a meeting you are just presenting the document to establish common understanding among the the people that are in the meeting so in in walkthrough you just present the document and gather feedback about the document from the team members in the meeting then it is led by the author of the document so author usually leads this walkthrough author does most of the preparation for walkthrough most of the preparation is done by author participants of walkthrough are from different departments and not required to do detailed study about the documents walkthrough is is just to give a clear understanding of the document to the people to show them what the document is and to gather feedback so uh the people in walkthrough can be from different departments different business backgrounds um business units it is not required uh during the walkthrough to for for people who are attending walkthrough to do a detailed study about the document as in the case of um formal review so and then walk through is useful for high level documents like requirement specification high level architectural document so walkthrough is useful in those kind of situations so suppose you are reviewing a requirement then in that case it's not a not a inspection or not a formal review kind of thing so you do a walkthrough to show the requirements that you have captured from different business stakeholders and you show them you walk them through and they decide whether the requirements that you have captured are perfectly fine or not or they they need some changes so you you get the feedback about those requirements and if there there are some missing requirements so all these kind of things are um taken care and walk through so people who are um attending walkthrough are not required to do a detailed study about the document then dry runs can be done too well to validate the documentation you you can also do the dry runs to validate the documentation that you have prepared now next type of review is um okay let's go through the goals of walkthrough so what are the different goals of walkthrough um the goals of walkthrough are to present document to the stakeholders from technical and business domains and gather feedback so the first and most important goal is to present the document to different stakeholders and acquire the feedback from them and the second thing is to explain and establish common understanding about the document so in walkthrough you not only gather feedback you also explain in case there is some doubt or there is some issues in the document you explain that document um to all the stakeholders so that everybody on the same page and everybody understands is common understanding has common understanding of the document to explain the validity of the proposed solution so in walkthrough you also validate the proposed solution so suppose the example of this would be uh like um doing a walkthrough of a software requirement specification doing a walkthrough of the design ui design or a mobile website design um so suppose you have a ui design you just prepared a ui design and then going to invite to different business stakeholders they come in you show them the ui design and the flow that will be followed for for the website how the flow will be and everybody and make sure everybody understands the flow and ensure that um the that the flow that you have explained and you have documented is valid and the solution that you are proposing to the business is valid and okay for them now the second one is technical review so technical review focuses on achieving consensus on technical content of the document so as as in the walkthrough it was more for high level documentation like requirements documents or ui document ui documentation or some high level design documentation but technical review focuses more on the technical content of the document how how things are implemented um will be implemented technically in the software so technical reviews are less formal than inspection so inspection is the most formal type of review technical review is also formal but less formal than inspection defects are found by experts like architects and chief designers so in technical review it is very important to take feedback from the experts like architects and chief designers about the technical content of the whatever you you write so if it is a if it is a design document or low level design document you get feedback from experts like architects and designers so technical review is documented is documented defect detection process which involves peers and technical experts so its technical review is is a documented process everything is documented whatever discussions are being done in technical review are documented and the people the the kind of people that are involved in technical review are the peers or peer developers or testers and the technical experts in the team and then performed as a peer review without management participation in technical review it's more of a of a team technical team that does this review and management is not participate management does not participate in technical reviews because it's mostly the technical content that that needs to be uh discussed in this sort of in um in this kind of review so management participation is not required in technical reviews then it is ideally led by a trained moderator or technical expert it is very important that technical review is led by trained moderator or technical expert because it requires in-depth understanding about um whosoever is uh leading uh this this review needs to be technically very sound to understand what discussions are being going on so he needs to be technical expert and then checklists logging lists issue logs are optional so as as this is not as formal as inspection so checklist or logging list you can you know these these kind of things can be optional in technical review then what are the goals of technical review to assess the value of technical concepts and alternative so whatever technical concepts have been implemented uh or are are being proposed in the document to assess the value of those concepts or if there is some alternative to achieve same task technically then inform participants about technical content of the document second most important thing is to inform the whole team how how the module or how the software system will be implemented technically so that's the second important goal then to establish consistency in use of technical concepts so there should be consistency among the team how um different concepts are being implemented will be implemented in the software so all the team should should be consistent should use those technical concepts consistently and have awareness of all the technical concepts then to ensure that technical concepts are used correctly so since in technical review there will be a lot of uh highly technical uh and knowledgeable people like technical architects and designers involved so they'll ensure that the technical concepts or the design or whatever technical design that has been proposed in the document that is in technical review is correct and doesn't require any change or if there are some changes required in that design or technical content and then um the other type of review is the inspection that's the most formal one so inspection is the most formal review type the inspection document is checked thoroughly by reviewers before inspection meeting so before going to inspection meeting it is thoroughly checked by the reviewers and any defects found infection inspection meeting are just logged discuss discussion about defects postpone until discussion phase so as we discussed the formal um formal uh review process so inspection is the most formal review process so it will follow the all the six phases of the review so um planning kickoff and then um you have uh inspection meeting wherein you log the defects and then finally um this inspection meeting will have three different phases logging discussion and then decision phase so inspection follows all that process uh the formal review process so any defect found in infection in inspection meeting are um just just log and discussion about them is postponed to discussion phase inspection is um led by a trained moderator and not by the author so inspection is led by a trained moderator it has defined role during the process it involves peer for examine examining the product so inspection involves peer your co-developers testers while you are examining the content or the document under inspection then defects are logged in the issue log so it's not like technical review technical review less formal issue log is option for that but inspection defects are always logged in issue log and it is a formal process based on rules and checklist with entry and exit criteria so it is a formal completely formal process and it has rules and checklists it follows entry and exit criteria as well then matrix gathered and analyzed for optimizing the process so in inspection whatever discussion whatever matrix or um whatever output has been whatever result has been there for the inspection after the after the inspection meeting then all those metrics are gathered and analyzed in order to optimize the process for the process review process what are the goals of inspection so the goals of inspection are to improve the quality of document under review so any any review any static testing technique the main goal is to improve the process or improve the quality improve the quality of the document to ensure that there are not there there are very few defects or there are no defects that are being transmitted to another phase in sdlc so um to improve the quality then remove defects as early as possible so goal of inspection is because you start review process or inspection early in the software development life cycle so you remove defects in early phases of sdlc then improve quality of product since you remove defects in early phases eventually you are improving quality of the software product then come up to a common understanding about document by exchanging information the other thing of inspection goal of inspection is that everybody is on it has a common understanding about the document because all the information is exchanged across all the team all the people who are reviewing or doing the inspection so everybody has to have the common understanding that's the another goal of inspection and then learn from defects found and improve the process the other goal of inspection is to improve the process since you found you find the defect then you find the root cause why those defects arise so you learn from your mistakes in order to improve