Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Leave a Reply

Your email address will not be published. Required fields are marked *