Informal reviewing

Informal reviewing

The most common way of reviewing in high-performance IT delivery is the informal review. Not many rules apply but the quality is still assured in an efficient way. We distinguish several approaches of informal reviewing.  

informal reviewing

Individual informal review 

An author sends a deliverable to someone of whom he expects that he/she is able to assess (certain aspects of) the quality of that deliverable with the request to review it. The other person then reviews it and gives feedback. That's all there is to an individual informal review. It is a very easy and low-cost way of reviewing. However, there is little insight into the breadth and depth of reviewing.  

The effectiveness of an individual informal review can be increased by using checklists or heuristics. Usually, the author is responsible for organizing the review process and for chasing the reviewers whenever necessary.  

Pull request 

When using a check-out / check-in mechanism for code, as is common in continuous

A pull request is a method of submitting contributions to a development project by which a developer, after making a change to code in a topic branch, asks for this change to be committed to the main branch (that is to be included in the main repository). This involves static testing (i.e. reviewing) of the changed code, for example to check if the change was done properly and if it complies with maintainability and other guidelines to code quality.  

The objective of the pull request is that the developer who changed the code asks another person to review the code and verify if the change was OK.  

A pull request is therefore an important review moment which is usually performed as an informal review in which tools such as checklists and heuristics can be used.  

n-amigos session 

The amigos approach is an approach whereby representatives of the various capabilities in a team get together to review a deliverable. In DevOps we commonly identify four capabilities in the cross-functional team, Business analysis, Development, Testing and Operations. They are called the four amigos. Whenever a deliverable needs to be reviewed, the four amigos study the deliverable and get together to discuss their findings. Because of the discussion and the exchange of views, a four amigos session is usually more effective than individual informal reviews.  

n-amigos

Model-Based Review 

In Model-Based Review (MBR), models are means to an end, the end being verifying that a deliverable is clear and complete. The tester composes one or more models so that end users, analysts, developers etc. can verify the tester's understanding of the subject. The sources could be tangible documents such as user story cards, but also "in the heads of anyone". The basic compelling idea behind MBR is that models are unambiguous by nature, so flaws such as incompleteness, inconsistency and incorrectness will be recognized more easily.  

Models also provide a limited view of reality; several models often need to be composed to represent a complete picture of what is in the design artifacts or "in the heads of" those involved. For example, a process is best represented by a flow diagram, but a "Yes/No" decision in that process could be subject to several basic "Yes/No" conditions. These conditions could be modeled individually and explicitly in the flow diagram, but the model of preference for conditions is the decision table or pseudo code.  

The model is often discussed within the team and with the stakeholders. After they agree that the model is good enough, it will serve as a basis in the development process, during test design and execution and in the operational stage of the IT system.  

Threat modelling 

In security testing there is a specific technique for static analysis focusing on the security characteristics. For more information see "Security testing". 

Other informal review techniques 

Like threat modelling there are more review techniques focused on a specific quality characteristic. Other forms of general static testing may also exist or arise. It is therefore impossible to be complete in this section.