Reviewing (static testing) | DevOps

Optimistic people may think: “What could possibly go wrong?” Realistic people will answer: “Anything!” DevOps teams are aware that in the process of IT delivery many things can go wrong. If a product is created and without second consideration deployed to the users, unpleasant surprises may happen. Therefore, every product should be looked upon by another team member than the person that created the product. It’s amazing what someone else sees in a product of which the author is convinced that it is perfect.

On this page you will see that executing tests on a ready-to-deploy product can reveal problems, but that it is much more effective and efficient to first review these products. These reviews are part of static testing.

  

Static and dynamic testing 

Testing consists of static and dynamic testing. High-performance IT delivery teams often strongly focus on dynamic testing. Mature teams have learned their efforts can be much more efficient by applying static testing. This is commonly called reviewing.  

Overview static testing 

Static testing consists of three groups of approaches with several approaches within these groups.  

_{Please note that the IEEE1028 standard also defines Audits and Management Reviews. Since these techniques are about reviewing the process instead of the product, we have not included these techniques here.}  

Static testing consists of three groups. We will discuss each of these groups in the following sections. 

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. (Button) (Button)

Formal reviewing In DevOps teams (as well as other high-performance IT delivery teams) formal reviews are usually not often applied. (Button) (Button)

Static analysis Apart from people doing reviews, tools can also be used for static testing. This we call static analysis. (Button) (Button)

Registering anomalies 

During a review anomalies are likely to be found. An often-recurring question is how to register these deviations between expectation and what is described. When reviewing a document, the anomalies may be registered with the document itself (for example as a comment using the word-processor). For reviews where the anomalies cannot be in the document itself a regular anomaly management system can be used, so that the anomalies from static testing and from dynamic testing are registered in the same system which facilitates easy follow-up.