Key Concepts of Code Inspection

What is Code Inspection?

Code Inspection is the process of reviewing and improving the code before testing.

Both testing and inspection aim at improving the code, but they rely on 2 distinct concepts:

  1. Testing is dynamic and executes the software to check its functionalities.
    (See also: Automated Testing with AscentialTest)
  2. Code inspection analyzes the source code based on a set of rules.

Manual, Automated or Continuous Inspection?

Several possible strategies for code inspection:

Strategy Description Pros & Cons
Manual Code Review Teammates review each other’s code to find and fix possible defects. Better code Human costs > limited frequency
Peer Programming 2 programmers at 1 desk: one writes the code while the other reviews it. Better code and Knowledge transfer.
Productivity can be challenging.
Automated Inspection Review performed by a machine. No limitations in the frequency.
Requires Code Analysis Tools
Continuous Code Inspection Automatic reviews included in a Continuous Integration Workflow. See below

Why Implement Continuous Code Inspection?

Continuous Code Inspection is meant to perform a complete code review each time a build is generated.
It reduces the time between the build creation and the discovery of the quality and/or security issues.

Below are some examples of objectives for continuous inspection:

  • Detect and remove security vulnerabilities
  • Comply with coding "grammar" standards
  • Comply with code readability standards
  • Architectural layering adherence
  • Remove code duplicates
  • Improve performance
  • And more...

Code Inspection and Continuous Integration

Types of Issues

Bug Flaw or mistake - other than syntax errors - that can break the application anytime. Fixing it is of highest priority.
Maintainability This quality-related issue is not a bug. It is not technically incorrect and does not prevent the application from functioning. But it makes changes way more expensive and increases the probability of introducing new bugs.
Vulnerability A flaw or weakness in code that could result in a security breach.
Security warning A piece of code that may create a security breach, but must be manually examined to determine it.
Metric Objective measurements of certain code properties or entities. Traditionally used for cost estimation, quality assurance, debugging, performance optimization, and task assignments.
Syntax error Grammatical mistake in the syntax of a phrase that can prevent the code from compiling or executing. Fixing it is of the highest priority.

Issue Severity

Not all issues are critical. To help prioritize improvements, each issue comes with a severity level:

Critical Bug that will probably alter the proper functioning of the application and must be fixed as soon as possible.
Major Security vulnerability, or bug that could possibly alter the proper functioning of the application. To be addressed as quickly as possible.
Minor Quality defect that can significantly affect the developer's productivity.
Low Quality defect that may slightly affect the developer's productivity.
Information Metric or information about the code.

How is the severity of an issue defined?

The severity level of an issue depends on its impact and probability.

High/low impact is evaluated with the following criteria:

  • For bugs: can this problem break the application or corrupt the stored data?
  • For vulnerabilities: if this breach were exploited, would it cause significant damage?
  • For maintainability issues: could this issue cause a developer to introduce a bug?
Critical Major Minor Low
Impact High High Low Low
Probability High Low High Low

Other definititions

Inspection Rule A coding practice that should be followed, to avoid generating bugs, vulnerabilities, or code quality issues.
Remediation Cost The estimated time required to fix all bugs and security issues.
Technical Debt The estimated time required to fix all Maintainability Issues


See Also:


PowerBuilder, Oracle, SQL Server, Code Inspection