I recently stumbled upon this tweet by James Clear: “Many problems are minor when you solve them right away, but grow into an enormous conflict when you let them linger. As a rule of thumb, fix it now.”
This was given as a general advice and, in my experience, this applies very well to software bugs. My corollary to it is: “The sooner now is, the better”.
In fact, the sooner a defect is caught and fixed, the less impact it will have on the users and on the company. Find an agreement on this is probably not too difficult, but achieving it in day to day work requires good organization and a thoughtful quality strategy.
The traditional approach to quality aimed to ensure that the final product meets some defined standards. In this model, a team of quality assurance professionals (QA) comes in after the product has been fully developed to detect any issues and faults with it before deploying to final users.
While this approach has been adopted for years across various industries, nowadays it shows some critical inefficiencies. For example, a few of them that are pretty common are that:
- QA comes in almost at the end of the development process and fixing issues by then is very expensive. At this point, in fact, developers may not have a fresh mind about something written some time before. Or more code could have been added on top of the flawed one.
- If final QA is the one and only validation step and it happens just before deploying to users, chances that issues fall into the cracks and get shipped are higher.
- QA teams are a single point of failure and they risk to become a bottleneck for the deployment.
As the industry has tried to solve these and other issues, a new model based on Quality Engineering has become predominant.
Quality Engineering works from the assumption that everyone involved in the SDLC is responsible for the quality at the stage where they are involved.
Under the Quality Engineering model, quality does not start and does not end when the product is completed. It’s a continuous effort that aims to gather as much information as possible at each stage of the SDLC to inform and improve the next cycle and to identify and fix any issue as close as possible to the stage at which it’s introduced.
In this context, the reorganization of the verification and validation phases so that they happen earlier in the development lifecycle – commonly known as “Shift-Left” – helps reduce the costs associated to issues. Fixing them requires less work and implementing multiple checkpoints across the SDLC creates a finer filter that reduces the chances that defects reach final users.
In my experience in different organisations, I found that implementing a successful QE model requires a shift in the organisation mindset: everyone involved in the development has to become a part of an extended quality team. Just like Agile removed the silos between stakeholders and developers, DevOps removed the silos between developers and operations, Modern Quality removes the silos between developers and testers.
This is a change that needs intentionality, planning, focus, and a not trivial amount of work, but that will eventually pay off with higher deployment velocity and great quality. I’ve found that some of the frameworks developed over the last few years are very helpful to inform and guide this migration (because, in many ways, it is a migration and as such it should be managed). If you are interested in this topic, make sure to checkout the blog in a few days as I plan to write about the ones that worked for me in the past.