trust factor in code review
Where I work, we have very few rules about what constitutes a code review. In addition to going through the code, I tend to briefly test out the software I'm reviewing (in my case, it's always our website) just to see if there are any glaring errors, at least if the project is large It has been the case where a code reviewer here has given anywhere from none to many suggestions in their feedback, but in fact the site did not load at all or simply did not function as it was supposed to.
There are also times when I look at the code and believe there may be a semantic error, but I would have to test it out to make certain.
Finally there are some very obvious errors that can come up from even brief testing that may not be obvious at all from looking at the code (or perhaps I'm just an inferior reviewer). Moreover, I think that some developers and testers may have a very different mindset in terms of how they use software, so a reviewer may find issues that a tester would not (and certainly vice versa).
I believe that code review is a very important step in the development process for catching errors in maintainability, semantics, consistency, standards, and even syntax. The questions I put forth are: should code reviewers actually test the software? If so, is it their responsibility or should this practice be controlled as part of the development process? If they are to test, how much testing is reasonable? If they find errors in their testing, how much time (if any) should they spend looking at the code to find the error vs. simply providing reproduction steps for the developer to debug on their own?