10 principles of continuous inspection
February 2, 2024
What is continuous inspection?
Let’s do a little memory. The continuous inspection is a new paradigm in code quality management designed to make software quality something internal to the enterprise, a integral part of the software development lifecycle. Continuous inspection enjoys a grassroots adoption among development teams, because its collaborative nature leads to truly collective code ownership and helps teams deliver better software.
It provides continuous code quality management and dramatically increases the ROI of a development project. The key concept in continuous inspection is to find problems early, when solving them is still cheap and easy. Under this model, automated code audits analyze the code of a project along multiple maintainability axes, test it for bugs, and compare it to equipment coding standards.
Audits are completed with tools that detect those problems directly in the developer’s environment, something like Microsoft Word spell checker.Team members receive an alert as soon as new problems are encountered so that they can be addressed as quickly as possible, while the code is still fresh in the developer’s mind. The timeliness of these alerts has the added benefit of empowering coders to eliminate bad habits and guide them to the good.
What to consider?
Here we leave you 10 principles of continuous inspection so you can apply now:
-
All parties involved in the development process - not just developers or administrators - must have immediate access to meaningful data about software quality.
-
Software quality management should be a concern of everyone from the start of development, but it is the ** ultimate responsibility of the development team.
-
Software quality must be part of the development process, which means that complying with quality standards is one of the strictest requirements for declaring complete development.
-
Software quality requirements should be objective and not require a subjective decision of approval/refusal.
-
Wherever possible, software quality requirements should be common to all software products, regardless of their specifications.
-
Software quality data must be up-to-date, that is, measured in the latest version of the code.
-
Software products must be ***continuously inspected so that errors are found quickly, when they are easy to correct. Developers should be able to detect new quality defects as soon as they are introduced, that is, inside the IDE as they write the code, similar to how spell checkers highlight errors.
-
Whether via push or pull, the parties involved must receive alerts when new quality defects are injected, either by sending an email, breaking the build or by other methods. The injection of new problems must be monitored, allowing teams to make quick and informed quality decisions.
-
Software quality data must be available as absolute values (in all codes) and differential values (in new code only) so that the development team can have full control of the incoming flow of issues.
-
All new problems and existing critical problems should be assigned a clear path and a time frame for their resolution.
Continuous inspection is well suited to agile and cascading development environments and addresses the shortcomings of the traditional approach. Continuous inspection offers improved quality with minimal disruption of the development process and timeline.
This article is based on this Sonar whitepaper
bitegarden team
Helping companies to develop better software