0

In my team I have applied a culture of code review and feature review.

The code might look great, written spectacularly, however the feature might not work.

It seems to me as 2 different scopes for review. While code reviews require a very technical and in depth knowledge, feature review requires only familiarity with the spec.

When I google code review I get a bunch of results. However can't find anything on any other kind of review.

A brief reference can be found at https://softwareengineering.stackexchange.com/a/92417/95463 where BillThor says "You were asked to review the code do so, it is not the same as testing it"..

Do you use other kind of reviews and what are their goals and process?

We use a feature review where someone is actually running the tests and the feature manually and verifies it is intuitive and applies to spec.

Community
  • 1
guy mograbi
  • 659

2 Answers2

4

Code review is just the first gateway to quality - not the only one. Its a very quick and easy way to ensure that what is going through to further verification is basically acceptable.

So it is to ensure there are no stupid mistakes, and that it passes whatever standards of code style or guidelines you have - code that looks wildly different to the rest of the codebase is very bad for future maintenance after all. Once this initial hurdle is passed, then you can review whether it works as intended, and performs as intended (such a non-functional feature is always implicitly present in all code changes yet only rarely mentioned as a feature). It can be checked for security processes or passed through static analysis tools.

So code review is just the "low-hanging fruit" of quality checks, that's partly why it gets done first.

gbjbaanb
  • 48,749
  • 7
  • 106
  • 173
3

You sort of answered your own question... "Feature" reviews are what integration and system tests do. In a requirements based test environment, the tests are developed independently from the code and are used to verify that whatever the code implementation turns out to be, it still does what the requirement said it should do.

If there are no requirements, or you don't develop tests based on requirements, then your development process will be missing the 'feature' reviews you're looking for. Note that informal testing by playing with the application and running it through its intended use is a form of feature testing. You're just not using written requirements, which becomes a bigger deal as the software's scope increases.

EDIT: Ultimately, your users are the final feature testers. It's always easier to find your own shortcomings than to let your users find them for you.

Kent A.
  • 880