Code review, Inspection & Walkthrough

Code review

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, and fixing bugs during later stages of development or after programs are delivered to users.

Reviewers read the code line by line to check for:

• Flaws or potential flaws
• Consistency with the overall program design
• The quality of comments
• Adherence to coding standards.

Code review may be especially productive for identifying security vulnerabilities. Specialized application programs are available that can help with this process. Automated code reviewing facilitates systematic testing of source code for potential trouble such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review is also commonly done to test the quality of patches.

Inspection

An inspection is, most generally, an organized examination or formal evaluation exercise. It involves the measurements, tests, and gauges applied to certain characteristics in regard to an object or activity. The results are usually compared to specified requirements and standards for determining whether the item or activity is in line with these targets. Inspections are usually non-destructive.

Non-Destructive Examination (NDE) or Non-Destructive Testing (NDT) describe a number of technologies used to analyze materials for either inherent flaws or damage from use. Some common methods are visual, Liquid or Dye Penetrant, Magnetic Particle, Radiography, Ultrasonics, eddy Current, Acoustic Emission and Thermography. In addition, many non-destructive inspections can be performed by a precision scale, or when in motion, a checkweigher.

A surprise inspection tends to have different results than an announced inspection. Leaders seeking to discover how well lower echelons in their organization are typically doing sometimes drop in unannounced to see what is going on and what conditions are. When an inspection is scheduled in advance, it gives people a chance to cover up or fix mistakes. A surprise inspection, therefore, gives inspectors a better picture of the typical state of the inspected object than an announced inspection.

Walkthrough

A walkthrough is a term describing the consideration of a process at an abstract level.

The term is often employed in the software industry (see software walkthrough) to describe the process of inspecting algorithms and source code by following paths through the algorithms or code as determined by input conditions and choices made along the way. The purpose of such code walkthroughs is generally to provide assurance of the fitness for purpose of the algorithm or code; and occasionally to assess the competence or output of an individual or team.

The term is employed in the theatrical and entertainment industry to describe a rehearsal where the major issues of choreography and interaction are practiced and resolved, prior to more formal "dress rehearsals".

The term is often used in the world of learning where a tutor/trainer will walk through the process for the first time. It is regarded as a literal walk through of the learning at the groups pace ensuring that everyone takes in the new knowledge and skills.

Something akin to walkthroughs are used in very many forms of human endeavour since the process is a thought experiment that seeks to determine the likely outcome(s) of an affair based on starting conditions and the effects of decisions taken.

Static testing

Static testing is a form of software testing where the software isn't actually used. This is in contrast to dynamic testing. It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors. This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.

From the black box testing point of view, static testing involves review of requirements or specifications. This is done with an eye toward completeness or appropriateness for the task at hand. This is the verification portion of Verification and Validation.

Even static testing can be automated. A static testing test suite consists in programs to be analyzed by an interpreter or a compiler that asserts the programs syntactic validity.

Bugs discovered at this stage of development are less expensive to fix than later in the development cycle.

A Waterfall Test Process

A Waterfall Test Process can be represented as figure shown below:

The description of each state is defined as table shown below:

I get the above information from Rapid Testing which is written by Chris Brown, Gary Cobb, Robert Culbertson.

Verification and Validation (V&V)

There are two basic functions of software testing: one is verification and the other is validation. Schulmeyer and Mackenzie (2000) define verification and validation (V&V) as follows:

Verification is the assurance that the products of a particular phase in the development process are consistent with the requirements of that phase and the preceding phase.

Validation is the assurance that the final product satisfies the system requirements.

The purpose of validation is to ensure that the system has implemented all requirements, so that each function can be traced back to a particular customer requirement. In other words, validation makes sure that the right product is being built.

Verification is focused more on the activities of a particular phase of the development process. For example, one of the purposes of system testing is to give assurance that the system design is consistent with the requirements that were used as an input to the system design phase. Unit and integration testing can be used to verify that the program design is consistent with the system design. In simple terms, verification makes sure that the product is being built right. We'll see examples of both verification and validation activities as we examine each phase of the development process in later chapters.

I get the above information from Rapid Testing which is written by Chris Brown, Gary Cobb, Robert Culbertson.