When we think about “Quality,” it usually is related to physical products. You expect the things to work correctly, last for a few years, and do what they are advertised to do.
But software is also a product, and it should be required for it to require certain quality standards. To understand quality in software, first, we need to understand what is quality:
how good or bad something is
Cambridge Dictionary
Pretty simple, right?
Now the problem is to apply the concept to the software. Software is not something that is generated in a production line, that each new item created has the certainty that it’s going to be of the same quality as the last one.
Each software has its own definition, its own characteristics, its own requirements. We can generalize that software is of good quality if it meets its requirements. But this is an oversimplification of quality because most of the time, the requirements themselves must be defined by the software developer.
To help with the definition of Software Quality, the International Standard Organization (ISO) first defined the ISO/IEC 9126 standard for evaluating software quality. In 1991, and later updated in 2001, and finally replaced in 2011 with the ISO/IEC 25010 SQuaRE (Software product Quality Requirements and Evaluation).
ISO/IEC 25010
This standard describes eight characteristics software must comply with to be considered of quality:
- Functional suitability: Does it do what is it supposed to do and gives the appropriate output?
- Reliability: Is it stable, fault-tolerant, can it recover to failures, and is it available when needed?
- Usability: How easy is it to use?
- Performance efficiency: Is it efficient in time and resources?
- Security: Does it protect its information and of its users?
- Compatibility: Can the app work on different platforms or share data with other products and systems?
- Maintainability: Can the software be easily updated, improved, and corrected if needed?
- Portability: How hard is it to be used as hardware and software evolves?
Having this standard can be used as the compass to measure the quality of software development. Still, if you want to read ISO’s definition, it costs 150 dollars… but hey, Google (Duckduckgo if you want to go private) has lots of information on it, so it’s possible to save that money! And there is a site that gathers information on all ISO 25000.
Quality is subjective
It will depend on what you define as perfect software, so it may not be perfect most of the time. But it’s a way to measure the work of what’s being done. But at the end of the day, as we can see in the standard, some stuff is based on common sense and may differ depending on what is needed. For example, software created ad-hoc for specific hardware will not comply in general with portability. Still, it will comply with the needs of the project.
Also, we can understand software from different perspectives, as software for massive consumption (like everything that is on the internet or mobile apps), and there is software created for specific use within organizations. For the last ones, normally it is a requirement that this software most not fail at all costs, because sometimes a lot of stuff depends on them.
But, is it vital for public massive application if there is a bug that happens once every time the sun aligns with Jupiter for that user in Antarctica (yeah, I’m talking about you penguins)? Nope, it’s not that important, and it doesn’t impact your software’s final quality. But, let’s be clear you must strive for perfection, and if bugs appear, try to solve them; let’s not be mean with penguins in Antarctica and leave them with bugs in their software.
Testing, testing, and more testing
As there is no perfect software, there is no silver bullet on how to have perfect software. But as software developers, we have the ability to test what we are doing and see if it works, if it does what it’s supposed to do, or if we need to classify any problem or bug as a new feature in the documentation.
Testing is our ally in the quest for bugs. There are tons of methodologies on testing and how to approach them. All the different tests can help analyze and discover if our code is doing what it’s supposed to do, and if it doesn’t do it, it is our work to fix it.
It may be frustrating to have to write tests and even may be considered extra-work. But, discovering any mistake early in the development cycle is preferred to have your user suffer from a weird error that erased their system32 folder in windows.
And that’s it?
Yes… but, no.
Software is an art that requires time and effort, there are tons of tools that can help in the process and help assure some of the quality standards requried by ISO. But at the end, you are the owner of your own software, and your final users are the critics of it.
Testing is a way to keep your critics somehow happy, but there are other techniques aswell. Like peer reviewing, what can improve your coding quality more than having the rest of your team judging every line you add to the codebase?!
So, yeah, as human beings is impossible to be perfect or to do perfect things, but it’s always good to try to do it, and at the end if something fails being humble to recognize the error and fix them.
