[The following is adapted from Rex Black and Jamie Mitchell's soon-to-be-released second edition of Advanced Software Testing: Volume 3, a book for ISTQB Advanced Technical Test Analyst candidates and other technically oriented testers.]

 Technical test analysts have a role in defining, applying, and maintaining design and code review checklists. Why are checklists important? For one thing, checklists also serve to ensure that the same level and type of scrutiny is brought to each author's work. There can be a tendency of review participants to defer to a senior person, and thus that person's work, when in fact everyone is fallible and we all make mistakes. Conversely, a less-senior or more-insecure person might feel threatened by the review. Regardless of the individual author and his or her skills, there is nothing personal about locating potential problems and improvements for their work from a checklist. The checklists serve as a valuable leveling and depersonalizing tool, both factually and psychologically.

 More importantly, though, checklists serve as a repository of best practices-and worst practices-that can help the participants of a review remember important points during the review. The checklist frees the participants from the worry, "What if I forget some critical issue or mistake we've made in the past?" Instead, the checklist gives general patterns and anti-patterns to the participants, allowing them to ask instead, "How could this particular item on the checklist be an important consideration for this work product that we're reviewing?"

 This idea of including not only best practices but also worst practices is important. Let's illustrate with an example. Consider the Common Vulnerabilities and Exposures list from MITRE, the Federally-funded non-profit, shown in Figure 1. If you are involved in reviewing code where security is important-and security almost always is important now-the items here can be incorporated into your code checklist and/or your static code analysis tools to ensure that dangerous coding mistakes are not happening.
 

Figure 1: List of top 25 security vulnerabilities from CVE website

Generally, what should go into a checklist? If there are common templates, style-guides, variable naming rules, or word-usage standards in the company for certain types of work products, the checklists should reflect those guidelines. Of course, the verification of some of these guidelines can be implemented in static analysis tools. In that case, the checklist or the review entry criteria can simply mention that successful completion of the static analysis is a pre-requisite to the review.

Visit our articles page to read this article in its entirety.

Webinar attendees are automatically entered into a drawing to win their choice of one of our green e-learning courses.  Visit our training page to see the complete webinar schedule, or just look on this email, sign up for a webinar, show up at whichever webinar session is most convenient, and--who knows--you might be the lucky winner of some valuable free training.  Either way, you're sure to learn something. 

Congratulations Zebian Ziyad, an attendee of the December webinar, for being selected as the winner of an e-learning course.

Register now for our next complimentary webinar, "Interviewing Testers", January 2 or January 6, 2015.