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:
- Testing is dynamic and executes the software to check its functionalities.
(See also: Automated Testing with AscentialTest)
- 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...
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.|
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?
|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|