In my recent series on
testing I concentrated on
dynamic testing, i.e. executing some or all of your code to see if it works. The other type of testing is
static testing. This was featured briefly in my "
SAS Software Development With The V-Model" paper at this year's SAS Global Forum ( SGF).
The principle form of static testing is peer review. Like all tests and reviews, you have to have something to test or review against. For testing you will have a set of requirements or a set of specifications (ref: the V-Model). For peer review, a fellow programmer will take a look at your code and offer opinion on whether it meets the team’s coding guidelines and other standards (and whether it gives the impression of meeting the unit specification). Thus, to perform an effective peer review, you need some documented standards against which the review can be set.
I wrote a
NOTE: post on peer review back in 2009, so I won't repeat those thoughts here; however, I did see a good
post from Tricia on the BI Notes blog back on October. Tricia used the post to run through a number of potential pitfalls for those who are new to the process. In the article, Tricia offered valuable tips on how to keep the review focused & at the right level, and how to be properly prepared.
Done properly, peer reviews offer increased code quality, reduced cost of rework, increased amounts of shared knowledge of your applications, and increased sharing of code and design good practice.
