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
  • 8
  • 11
  • 2
    You also need testing and you may also want [static program analysis](http://en.wikipedia.org/wiki/Static_program_analysis). – Basile Starynkevitch Mar 10 '15 at 09: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 Mar 10 '15 at 09: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 Mar 10 '15 at 10:46
  • The overall picture is better known as software quality assurance (SQA), and partly related to trustworthy computing in areas where it overlaps with information security. – rwong Mar 10 '15 at 10:48
  • See [Best Kept Secrets of Peer Code Review](http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf). Chapter 3 is named: Five Types of Code Review. – edalorzo Mar 10 '15 at 12:48
  • 1
    In agile programming feature review is baked into the methodology. – Hogan Mar 10 '15 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 Mar 10 '15 at 14:50
  • @rwong There is some level of testing that is fundamental to any programming and does not require a specialist. For example, when you code "Hello, world!" it is implicit that you actually run it and see for yourself that it does indeed print "Hello, world!". Obvious next step is to automate this idea so that you can apply it efficiently throughout your code. This level of testing is analagous to spell-check for a secretary. If you don't do it yourself, you will look unprofessional at best. – Brandin Mar 11 '15 at 13:23

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,354
  • 6
  • 102
  • 172
  • Can you please elaborate? who does the other reviews? what tools exist to give feedback and monitor it. – guy mograbi Mar 10 '15 at 09: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 Mar 10 '15 at 09: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 Mar 11 '15 at 00: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.

Kent A.
  • 880
  • 4
  • 9