There is more to software quality than preventing bugs. It also gives us the opportunity to reach better code. From the different levels of quality to the various incentives to evaluate quality, there are many paths to software quality.
Fortunately, there are many tools producing software quality metrics: by analyzing the code structure and complexity, checking compliance to rules from a standard, verifying coverage, measuring execution times, etc.
Let’s explore how these metrics can be the building blocks to compute aggregated quality objectives, that will help focus on the code needing attention, and define the quality checks to reach healthy quality habits.
Software quality levels
From the starting days of software quality some decades ago, when the quality of the software was met as soon as it ran without crashing, a lot has been discovered and proposed.
Firstly, software projects became more complex and connected to an ever-growing number of software layers. These layers are in turn developed using the same principle, producing a rich and intricate combination.
Second, software quality assessment has also been growing, including new concepts, techniques, regrouping them in standardized recommendations.
Level 1: Software quality metrics
The first and most straightforward way to assess quality is by way of software quality metrics.
In essence, these are project measurements, coming straight from analysis tools run on the source code. Static or dynamic code analyzers, programming rule checkers, or test coverage solutions. These tools generate precise information for each function or file in the project and are used to great benefit.
Then all you have to do is parse these tools’ logs or dashboards and verify that metrics meet expected thresholds.
It is quite easy to put into practice but can become a daunting task for big projects. Tens of thousands of lines of code may produce huge quantities of metrics.
Background information
Level 2: Software quality model
A quality model’s primary function is to provide high-level quality indicators, which computation is based on quality metrics. This means these indicators translate quality good practices into approved and reliable computations. So, a good quality indicator will help detect what piece of code needs attention, without having to parse all metrics in search of an outlier.
The knowledge produced by a software quality model has a higher level of abstraction. Its goal is to help understand what these metrics actually mean. But you still have to work out what to do and ask yourself “Is this 9% comment rate OK?“
Background information
- Software quality powers explained
- Software quality rating model
- Overall software quality
- Software quality temporal monitoring
Level 3: Software quality scorecard
The quality scorecard is like the expert’s final rating after a thorough analysis. If you trust the expert, that rating gives you an assessment of the code quality as a whole. But a scorecard shouldn’t only qualify the tip of the software project, it has to qualify each and every file, class, function. And speaking of trust, the scorecard is fully based on the software quality model results, which is itself an implementation of good quality practices.
The power of a quality scorecard is that it provides a synthesized vision of the project, checking if it’s in good health quality-wise. Also, it allows fast detection of pieces of code needing attention because of a bad or deteriorating rating.
Background information
- Software quality powers explained
- Software quality rating model
- Inside software quality
- Overall software quality
Software quality incentives
We saw that the motivation behind software quality is not just about the bugs anymore, but better quality for the code. Beyond that noble intention, quality is also an expected result of the software production chain. And that expectation doesn’t stop at the development team. Several levels of stakeholders can require specific quality levels to validate a software product.
As a consequence, software quality has to be followed, monitored, reported, and justified. This can seem like a lot of work, but it doesn’t have to.
Level 4: Quality management
Quality is also in the eye of the beholder. From the perspectives of the development team, project manager, company, or external client, code quality is different things. From precise function-level test coverage to standard compliance, maturity level or industry-specific indicators, all these quality attributes need to be part of a quality project and managed like any other project.
Whatever the level (metrics, model or scorecard), software quality management answers to a need to follow and communicate the current state of a project’s quality to parties that are not necessarily involved in the project daily lifecycle.
This is a sensitive task, which can miss the objective if it produces too large, highly detailed reports.
Background information
Level 5: Quality gates
We can see software quality as an agreement between two parties, and quickly visualize examples. The project manager checks that programming guidelines are followed by the development team, and then verifies the standard compliance. The auditor has a checklist of indicators to validate. The client needs to know if the project quality requirements are met.
Software quality gates handle all these cases, as specific verifications on the project quality assessment. It doesn’t replace or cancel a regular quality report, but it acts as a checkpoint (hence the name ‘gate’) to quickly answer the question “Is the project fulfilling the agreement?”. Of course, the agreement must be defined from the beginning, but that’s also what the quality gate is for. To share from the start what is being checked.
Background information
On the top: Quality in the process
Software quality can be costly, if teams are mobilized each time a quality audit takes place, or if the process sets quality assessments phases before each release. Quality reports will be produced, gates will be crossed, but the price might be loss of motivation and distrust of the benefits of software quality management.
There is no “Reach Quality Now” button, but introducing quality practices in the development process, sustaining quality awareness by regularly communicating quality assessment is a good way to reach a built-in quality scenario.
As with all changes, trust in the results and smooth transition is the key to adoption.
Background information
- Software quality: To the rescue!
- Software quality: Winning as a team
- Inside software quality
- Monitoring software quality
- Software quality for the team
Conclusion
Whatever the quality level or incentive combination, software quality is as important as the actual software product. It determines how well it will evolve, how heavy maintenance will be, or simply if it will be accepted or refused.
This is especially true in a continuous delivery scenario: quality takes the center stage as a means to simplify assessment and streamline validation.
Software quality metrics in practical examples
- Software quality monitoring: Real use case
- Open source quality check: Overview and background
- Dashboard with software quality metrics for Keras, Laravel, Mantis and many more (powered by Squore)
4 thoughts on “Software quality: From metrics to habits”
[[..PingBack..]]
This article was curated as a part of #48th Issue of Software Testing Notes.
https://softwaretestingnotes.substack.com/p/issue-48-software-testing-notes
This is Best Article
Hello Mohamed,
Thank you for your feedback!
Software Quality can sometimes feel as being expensive to deploy, but it really pays off in the mid and long term
Flavien
It’s nice