Monday, May 05, 2008

Peer Review Your Tests

Software review has been around since the 70's, but one place I see it skipped over often is in the test world. Why would anyone want to peer review your test cases? The answer to that is, why wouldn't you?

It seems to me that many testers don't have their code reviewed because it often does not intermix with anyone else's code. This is one problem that leads you to owning "your" parts of the code and ignoring "someone else's" code. This creates a sort of hands off environment where people begin to guard their code and resent when someone else is prodding at its inner workings. This is where a culture of voluntary peer reviews can help bring the test teams together into a more cohesive, and open unit.

I say voluntary because formal reviews do not sit well with developers (or anyone else involved for that matter), because of the stiff formality and time spent reviewing. The best way to get a team of developers reviewing each other's code is to introduce it and start using it yourself first. Once the benefits become clear, the stragglers will be interested. Also, by keeping the code reviews informal and voluntary, the reviewee's attitude is much different than if they were being forced to do a review.

So what benefits does a test team gain from using a peer review system? Just the same as they have been argued for developers. A good peer review setup will help keep your test cases consistent and readable among the differing 'silos' of tests in your suite. Also, by showing your code to your other teammates they can save you time debugging if they spot a problem with your testcase. This, to me, is one of the most valuable assets to a code review system. If someone can point out a problem before I waste time on it, I'm eternally grateful. The second most useful aspect of code reviews have absolutely nothing to do with finding bugs. The side effect of doing a peer review comes in the form of skill transfer. If I'm working on some web service tests and I'm reviewing tests for web services security, I'm going to pick up how their tests work as well as how the web services security works. This can also help foster another important and very useful activity within the team, mentoring.

While there are many more reasons why you should implement an informal peer review system, I'm going to leave what I have at this and open up to discussion on peer reviews. How have they worked for you and how did you implement a code review system? Let me know in the comments.

No comments:

Post a Comment