Just add on to the answer, a peer review is not just about the code review. It helps in:
Identifying improvements in code logic
Identifying improvements or missed application logic in the test
Identifying easier test approaches to improve test coverage
Identifying better approaches to solve a problem.
and so on.
We all will have mind block and ...
Branch the code before review and merge it into the main release branch after the review is accepted/completed. See this blogpost for more idea's: http://share.ez.no/blogs/arne-bakkebo/branching-and-code-review-procedures-qa-4
For Subversion you can look into simulation shelve-sets and let the sets be reviewed before checked-in: http://jason.famularo.org/...
When working in teams one of the most important added value of code-reviews is knowledge sharing. This leads me to think that other developers on the team should do the reviews and not testers who do not add code to the code-base.
I suggest you read the free (relative short) e-book "The best kept secrets of peer code review", its totally worth the read if ...
From my experience, it's useful to do the peer review for the test cases (review the test design itself).
If you automate the e2e tests, the code should be reviewed as well.
If you want to have a good test automation project - you should treat it like any other software project, and apply all of the best practices, including the code review.
The thing is ...
But I want to know if there are other reason.
I can think of some that I have personally encountered:
tight budget, so business people will not give you the necessary time for reviews even if it hurts the project in the long run and you keep explaining for weeks on end; you can perhaps work overtime for half a year, but they you don't have the energy, or ...
My answer appears to fly in the face of the other answers so far. I think code reviews are a very valuable way to keep QA informed, and to understand what they are testing at a much lower level. Primarily for the same reason I think having code coverage results on manual and automated test passes are important, I think code reviews are also important.
First google Exploratory Testing.
Some ideas for testing might be-
yours, and your customer's expectations and needs (what is the program used for)
similar programs (compare to other knowns)
relevant standards, or de-facto and industry standards (from national or international standard bodies e.g. ISO/IEEE/FDA etc. other sources might be known practices)
Is it fair? I suppose that depends on the context - who you ask and what their definition of fair is.
I think an important consideration of opening bugs without evidence of a problem is that it could reduce your credibility in the eyes of the bug report readers.
Bug Reports are the primary work product for testers. They are the tangible work most seen by ...
As a fellow QA engineer, my advice to you is: don't.
If you'll be reviewing code, you'll be partly responsible for the code's quality. But to do this task thoroughly, you need to have sufficient expertise and experience.
Do you have a clear view on the framework, the legacy code? Do you know common best practices for Java programming? Are you up to date with ...
How about: "If a job's worth doing it's worth doing well!"
Why do we review other peoples work, because they are sloppy? No, I believe in continuously improving in small steps, someone has to monitor what needs improving though :)
Given the mandate to use Microsoft Office, I'd look at using spreadsheets to manage the test execution, working something like this:
The master list of all test cases for the project is either a Word document or an Excel spreadsheet, linked from the Test Plan.
Each test run can be either a separate spreadsheet or a worksheet within a single spreadsheet, ...
This is a huge question!
I've worked at similar places where they want a QA team to work without the QA tools like bug-tracking software, for example.
If you're being forced to use Microsoft Office, then it might be worth splitting up the document, so rather than tracking the defects in one test document per iteration, you could literally have one page per ...