Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Does anyone practice the "code review" process for functional tests? Do you find it useful? The way that my current employer practices SCRUM we include functional testing as part of our "must have done" stuff in any given sprint.

share|improve this question
I assume you're also placing your tests under revision control... – chrisaycock Dec 13 '10 at 17:33
We use TFS to store everything and manage our entire process. So far it is working well. – Ryan Pedersen Dec 13 '10 at 19:15
up vote 3 down vote accepted

We also practice SCRUM. And the same as you, we also include functional testing as part of our definition as done.

From my experience, I find it incredibly useful. We have significantly reduced the number of bugs in our code by simply forcing the functional testing.

A second nice thing about the code review, is it gives you another view over the actual functionality, and to make 100% sure that it is in line with what the customer/client wanted. There has been a few times when someone was going over code and functionality where the person went ... "Hang on, this is not right..." and it turned out that the person implementing the code just misunderstood something.

share|improve this answer

Good heavens yes (I try not to use expletives on SO ;p). Peer reviewing your functional tests is basically peer reviewing your requirements and analysis, it's incredibly important, and if you use a BDD language like cucumber you can involve non programmers as well!

It's awesome when our end users spot issues with our functional tests and it makes them feel hugely part of the development process "I can read code too!!"

share|improve this answer
Unfortunately, the "I can read code too!!" moment will make some think your job is simple and that they could do it... – CaffGeek Dec 13 '10 at 17:44
@Chad - I quickly disabuse them of such ideas by showing them a multi-threaded XA SFTP JCA connector :). But I see your point. – Martijn Verburg Dec 13 '10 at 17:46

It makes perfect sense to me. Any code you write should be looked at by someone else, even if the code is only used internally and will never be run by the customer.

share|improve this answer

With the methodologies that put so much weight in testing the review of the tests becomes much more important, possibly required, sometimes more important that the review of the code itself since it is often assumed it can be replaced with any code that meets the same automated testing outcome.

Reviewing that the tests are correct is one aspect, that they are complete enough and accurate/representative is also very important.

Missing this point is one of the things that makes these methodologies look sloppy to outside reviewers.

share|improve this answer

You can do pair inspections!

Pair Inspections are:

A review of documents actively & informally as part of the authoring & document production cycle.

The reasons why this works well with testing is that:

  1. You can frequently inspect requirements or documents with more than one pair of eyes.
  2. You can involve more than just developers: Try BA with Test Lead, BA with a PM, BA with Dev.
  3. You can set re-curing meetings as part of an Agile process – Make sure to be serious about it with solid commitments from team members.
  4. You can use these pair inspections as part of a rapport-building exercise and communication exercise with your stakeholders. Get the conversation going!
share|improve this answer

We peer-review functional tests at least casually, and it is strongly encouraged at our organization to get everything code-reviewed.

I would recommend choosing your reviewer based off of your goals for the review. Coded tests might be best reviewed by both a dev (for code quality primarily) and another tester (for test coverage primarily). Tests with no code (using a harness, e.g., data driven tests) might be best reviewed only by another tester. Peer reviews are also a great way to encourage testers to learn from each other.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.