ALM Best Practices

Code Review and Requirements Review: Automating Human Review Tasks

By Adam Kolawa, Parasoft CEO and Co-Founder

No matter how much automation is in place to assist the development and QA teams to deliver the right code faster, humans must read, understand, and translate information into critical SDLC artifacts.

From Parasoft’s 20+ years developing code, we have learned that one of the primary keys to both productivity and defect prevention  is the automation of human review processes (for example, peer code review and requirements review).

Ingraining critical human review tasks into the software development lifecycle yields significant benefits—not only to overall application quality, but also to team productivity. Human tasks generated to remind someone to double-check their own work or to review their peers’ work drive developers to gain greater visibility of the broader application. Ultimately, this delivers significant gains in productivity.

Two Pairs of Eyes Are Better Than One: Peer Code Review

This leads to another very valuable quality component that is delivered as part of Parasoft Concerto: automated peer code review. Just as there is no substitute for an individual reviewing his or her own work, having the individual explain that work to a peer is priceless. Unfortunately, the practice of code review is often delayed, cancelled, or avoided as rework is required and deadlines creep up.

Parasoft Concerto automates the peer code review process and prompts developers to execute peer code review tasks as an essential part of the SDLC. The practice and conditions of peer code review are centrally managed as a policy within Parasoft Concerto, and all comments made during these reviews are recorded for easy retrieval.

Contextual peer code review can also be accomplished to meet distinct regulatory requirements such as PCI, CWE/SANS, and MISRA. This can also drive guidelines for initiatives like secure application development.

I talk more about how to uncover more complex defects during peer code review—without impeding project progress—in my Code Review Best Practices white paper.

Checking it Twice: Double Implementation of Requirements

Getting developers to perform “double implementation” of a requirement ensures that a level of objective interpretation is baked into the software development cycle. Double implementation of the requirement means that the developer is required to have at least one test case for every requirement that is being implemented.

When such a practice is enforced, developers are obliged to think about the requirement from two different perspectives. The first perspective is the actual implementation of code. The second perspective is the creation of a test case. This not only ensures a review of the requirement, but also creates an artifact that holds the requirement’s business assumptions stable in a changing application.

A system like Parasoft Concerto drives this practice by reminding developers when they need to create test cases for the second perspective. By flushing functional errors as well as prompting independent code review, this prevents a ton of rework later in the development process. Moreover, the system also ensures that you will see a test case break far before you know that specific code changes have impacted related components of an application. This essentially establishes a baseline for Change-based Testing as well as Change Impact Analysis.

***

Code Review Best Practices: Learn your team can uncover more complex defects during peer code review—without impeding project progress... read Adam Kolawa's Code Review Best Practices white paper. Or, learn more about Parasoft's Code Review.