A few weeks ago on the agile testing list, a developer in a tester role asked about reviews – Where do they fit in the agile process? Lisa (www.lisacrispin.com) and I didn’t directly answer this concern in our book, so here are my thoughts about this subject.
Organizations handle reviews differently, but I like to see the developers take responsibility for their code and believe they should take accountability for code reviews. If the developers create standards for the team to follow themselves, they are more likely to follow them. There are tools that can be run during compilation to catch easy errors and can be used to supplement more extensive reviews of the code.
My personal preference is for developers to do pair programming. This not only ensures a better design (two perspectives on the code), but also gives a ‘real time’ code review.
My second choice is peer reviews, with the coder walking through what they have done with another developer immediately after finishing coding (or if they are having trouble). This has a few advantages. First, it is a few direct method of getting quick feedback. Also, articulating out loud makes people think differently, (http://c2.com/cgi/wiki?RubberDucking) and developers will catch many errors themselves. The added benefit of peer reviews (or pair programming) is the cross-training that happens so shared code ownership is easier to adopt. Another advantage that I can think of immediately is its relatively low cost compared to formal code reviews that take several people’s time. Personally, I think it is more effective as well.
When I test, I like to include reviews by developers and other testers for my own tests that I create. I find the more people that have input into what I test, the better the tests are. Developers give me many great ideas for exploratory testing as well, since they know where the weak spots of the code exist.
Many teams include reviews in their definition of ‘Done’. If you are having problems putting peer reviews into practice, one idea I have found useful when starting new practices, is to either write a separate task card, or use the testing column of your story board to mean reviews for programming or testing tasks.