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.

Improve this question
8
  • 2
    You also need testing and you may also want static program analysis.
    – Basile Starynkevitch
    Commented Mar 10, 2015 at 9:28
  • 1
    This seems like a bit of a list question, which does not generally fit well on SE. Could you clarify what you want to know?
    – jonrsharpe
    Commented Mar 10, 2015 at 9:48
  • The other aspects, such as testing (finding defects by actually executing code), security testing (penetration or adversarial), or performance monitoring are highly specific and require dedicated persons working in those aspects. Whereas code reviews can be performed by most people, the latter two tend to require specialized knowledge.
    – rwong
    Commented Mar 10, 2015 at 10:46
  • 1
    In agile programming feature review is baked into the methodology.
    – Hogan
    Commented Mar 10, 2015 at 13:45
  • 1
    When I worked at Lucent, I think we had 4 level of reviews in our department alone: Requirements, High-level Design, Low Level Design, and Implementation. Business probably had more than one layer of reviews as well.
    – MSalters
    Commented Mar 10, 2015 at 14:50

2 Answers 2

Reset to default
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.

Improve this answer
3
  • Can you please elaborate? who does the other reviews? what tools exist to give feedback and monitor it.
    – guy mograbi
    Commented Mar 10, 2015 at 9:32
  • Up to you, security analysis is done by someone who is more of a domain expert for example. It doesn't matter who does them as long as they're effective, otherwise why bother doing them at all.
    – gbjbaanb
    Commented Mar 10, 2015 at 9:37
  • Code review is also one of the few reviews that's worth doing for every single change. Feature review may only make sense once every several code changes (in our agile workflow, it happens once per sprint). Security review is best done to the whole product rather than individual changes to it.
    – Ixrec
    Commented Mar 11, 2015 at 0:58
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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