What drives Quality: Review and Inspection

My 2nd book What Drives Quality is available on Amazon, in my webshop, and in all other major bookstores.

The 5th posting on on “What Drives Quality” covers review and inspection. Previously postings covered Requirements Quality,  Architecture and Design Quality, and Coding Quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.

Reviews and inspections are techniques to investigate and discuss code or documention, to improve it’s quality. It can be done by finding defects, reporting and discussing them in a meeting, and having them removed by the author. This approach is called “cleanup mode”. But often it is more practical to sample code or documents, identify the quality by finding major defects, understand why those defects were inserted and use this knowledge to rewrite the code or documentation in such a way that those defects will not be made again. The focus for the second kind of reviews and inspections is on learning and defect prevention, by using reviews as a source to do Root Cause Analysis.

Some of the factors that drive Review and Inspection Quality are:

  1. Review and Inspection Policy and Strategy – The policy states the business benefits expected from reviews and inspections, the strategy describes which reviews and inspections are performed in the project and which kinds of defects are expected to be found in them.
  2. Review and Inspection Process Adherence – Checks such as audits or assessments to determine whether the baselined processes are being followed and if they are effective and efficient.
  3. Review and Inspection Capability – The skill and experience level of the people doing reviews and inspections.
  4. Review and Inspection Process Maturity – The quality of the defined and baselined processes, including all supporting materials such training and templates.
  5. Coding performance – Quality of the code resulting from the previous implementation phase prior to inspection.
  6. Project Management Performance – Definition, planning, tracking, and control of quality in the development projects and the delivered products.
  7. Process Management Performance – Defining and baselining the processes to be used for management and technical work. The support in operational usage of the processes for training, instructions, tools and templates and the availability of websites and experienced personnel.

Software reviews and inspections significantly improve the quality of products, and provide major savings in cost and time. They provide significant business value, if there are done by skilled profesionals guided by a policy and strategy. Reviews and inspections can be documented in a test plan, thus becoming part of the verification  and validation strategy for a product. But remember that Quality Assurance is much more then testing, as described in the Real QA Manifesto, real benefits come from defect prevention!

Various techniques exist to improve the effectiveness and efficiency of reviews and inspections.  Some examples are:

  • Focused reviews, eg. perpective based reviews, role based reviews, dividing the document to be reviewed over the reviewers, etc.
  • Collection of remarks before the review meeting, and distribution of all combined remarks to the reviewers
  • Design and coding rules (rule based reviews); this can be combined with static code analysis
  • Statistical and/or Six Sigma techniques, like sampling, capture-recapture, preparation time vs defect density, etc

Moderators play a crucial role in the review meetings, by focusing in the process they assure that minimum time needs to be  invested by the professionals to get maximum results. Much time can be saved by making a selecting which defects need to be discussed in the review meeting, and which ones can be corrected directly by the author without further discussion (of course the author can always contact the reviewer if (s)he needs more information). I have seen moderators who were able to analyse major defects with the reviewers, understand the causes, and come to preventive actions so that those defect would not be made in the future. Other moderators used parts of the review meeting to explain and emphasize coding rules, when it turned out that those rules were violated (often because programmers didn’t understand them).

When you start with reviews, assign a review coach that attends the meetings and provides feedback at the end of each sessions, to continously improve review skills. As a quality manager, I usually attend the first couple of review meetings to do retrospective with the attendees, and help them to be more effective. Mistakes that happen often are lengthly (uncontrolled) discussions, attacking the author, and attendees that feel the need to make remarks to show off and make themselves important. By adressing and discussing this with the review team, with feedback on what happende during the meeting, teams are able to learn and improve quickly.

At one time, I was asked to moderate a formal review meeting of an architecture document. When starting the meeting, I asked the attendees if they had prepared for the meeting, by going through the document and making a list of the defects that they had found. Several attendees explained that they had not been able to prepare, as a result I cancelled the meeting, after asking attendes that had prepared to share their findings with the author in an informal way. A new date was set, where attendees committed that they would prepare themselves and sent in remarks before the meeting. Directly after this meeting, the project manager who wanted me to moderate the meeting asked me to his office. At first he was quite annoyed, he had never seen any review cancelled before, and didn’t expect this behavior from his quality manager (it was my first day at the job!). When I explained the risks that would be involved by having the review done with insufficient preparation, he changed his mood and complimented me on taking this decision. He explained that it had happened more then once that significant problems turned up late in projects, which gave major disturbances and delays to delivery dates. After listening to me it became clear to him that by having done well prepared reviews such problems could have been prevented, and he certainly didn’t want this to happen to his project. At the new review meeting, everybody was well prepared. The meeting took less time then usual, and there were several findings discussed that would have turned into major bugs later in the project.

Reviews and inspections are effective techniques to increase the quality of your products, and find defects earlier at lower costs. They can also be used to convey knowledge about the software witin the team, and to learn and improve developer skills.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.