Software quality or the quality of software is a topic that generates many debates within the software development community. Is it about user satisfaction? Does it deliver value to the organization? Do we consider the quality of the code or its capability to change in the future, maybe with some automated tests to make sure nothing breaks? How good is “good enough”? In his book “What Drives Quality” Ben Linders tries to provide an overview of the quality perspectives during the software development life cycle.
If the answers to the above questions might differ according to the context, Ben Linders explores the different aspects of quality linked to software development activities, from requirements to testing and operations. Instead of writing an encyclopedia, he provides many links to external resources that allows the reader to dig deeper in a specific topic. The book is easy to read as the conceptual content is balanced with use cases and practical tips. If I am a little bit skeptic with the suggested mandatory link between Agile and quality proposed by the author, I am sure we will both agree that quality comes from the people mindset, both on the software development and the user sides. Procedures, checklists and automation might help and provide a structure to the software quality process but the old expression “garbage in, garbage out” is still valid.
I will recommend this book to any software developer, tester or project manager that wants to have a global perspective of quality in the software development life cycle.
Reference: What Drives Quality, Ben Linders, 100 pages, https://leanpub.com/WhatDrivesQuality
Website: https://www.benlinders.com/what-drives-quality/
Quotes
Still, many companies struggle with changing their process from “testing or inspecting quality in” to achieving quality from the start – through culture, design, craftsmanship, and leadership.
I see organizations that try to fully automate their coding rules, for instance with automatic code checking in their version control system. Any piece of code that does not comply to the rules will be rejected at check-in. Programmers often dislike this, as a result, it decreases productivity and often hampers quality. Programmers will look for ways to bypass the code checking system. They may be allowed to bypass it in times of pressure which opens the door for bad quality software.
It is better to train and coach programmers in writing good code than to use a tool that bashes them. Most coding rules also have exceptions, a good programmer knows when to apply a rule, and when not.
Many teams try to automate far too much existing test functionality. My advice is to use a risk based approach for deciding what to automate to prevent spending too much time maintaining and debugging test automation.
Let’s suppose that something goes wrong. What’s the worst that could happen? Ok, there are situations and quality issues that you definitely want to avoid (for example, when human lives are at stake), but quite often it’s not so bad if something goes wrong or if there’s a bug in our software that we can solve easily and quickly.
We still suffer the most from the fear of being ridiculed, but there’s no need for that, so let’s change that. We also make it worse by blaming people for mistakes. Often that’s a diversion, because let’s be honest: who doesn’t make mistakes? A culture in which you can make mistakes, in which you can honestly say that something went wrong, that you are unsure of something, is much more effective. In such cultures it is also easier to use the experience and strengths of employees to find solutions together.