Quality by Design (QBD) refers to the approach of ensuring software quality not through downstream testing, but through the targeted design of the development process itself. Errors should not occur in the first place. This involves analyzing risks in the process, defining measurable quality characteristics and continuously controlling the process using concrete metrics.
Key Takeaways
- Preventing errors from occurring in the first place is more economical than finding and fixing them through testing: Quality by Design aims precisely at designing the development process in such a way that quality is built in instead of tested afterwards.
- Software quality and source code quality are two different things: the former describes the benefits for the user, the latter the measurable quality of the code, and both need their own metrics and measures.
- Anyone who does not systematically check artifacts such as user stories for completeness is working on a fragile basis: in one specific project, sixty percent of the tickets were incomplete, which led to interpretation errors and unnecessary feedback loops.
- Quality by design is not a framework to be set up, but a cultural change: every person in the team is responsible for quality, and this attitude is not created by regulations, but by a shared understanding of what is at stake.
- Those who introduce metrics should start with a few, targeted measuring points at neuralgic points and monitor these consistently instead of setting up a comprehensive system of key performance indicators from the outset.
Quality by design shifts quality to the front
Quality by design means building the development process in such a way that errors do not occur in the first place, instead of looking for and removing them afterwards. The approach originates from the pharmaceutical industry and can be transferred to software development.
Many companies equate quality with testing. Testing is important, but it only takes effect when the error is already in the product. Alessandro Sebaste describes the basic problem matter-of-factly: you produce errors in order to look for them and remove them again. It would be smarter not to produce them in the first place.
This is exactly where Quality by Design comes in. The focus shifts from testing the end product to the process that creates the product. In pharmaceuticals, this is the manufacturing process; in software, it is the software development process.
How does Quality by Design work in the pharmaceutical industry?
In pharma, everything starts with a Quality Target Product Profile, or QTPP for short. These are the user requirements for a medicine: it must be safe, it must work, it must be affordable, and nowadays sustainability is also a factor.
The critical quality characteristics that can be measured in the manufacturing process are derived from this target profile. At the same time, we constantly ask what can go wrong in the process so that this quality is not achieved. A risk analysis is used for this purpose.
The process is then developed in such a way that it is continuously measured and monitored. Thomas Gsponer summarizes the goal: Defects are not built into the product and end product testing is reduced.
The approach rests on two pillars. The first is risk analysis, the second is continuous improvement. Both apply to software in the same way as to a drug.
Software quality and source code quality are not the same thing
If you want to control quality, you have to distinguish between software quality and source code quality. Both have a different focus and require different measures.
Software quality is reflected in features that the user experiences. Software should run stably, perform well and be easy to use. The power consumption of an application is also increasingly becoming a customer requirement. The key question is: What does the customer need and what does the customer’s customer need?
Source code quality is the level below this. This is about the building blocks from which the solution is created.
This results in a differentiated approach to agility. How an application is built should remain open. Fewer compromises make sense when it comes to the components you use. When writing code, fixed rules apply up to a certain point, after which the team can be flexible.
Metrics only when they lead to decisions
A metric only has value if someone derives a change from it. Many teams let a tool spit out numbers and never use them to understand where things are going wrong and what could be improved.
Quality by design turns the relationship around. You don’t make changes based on gut instinct, but on values. Measuring, understanding and targeted intervention belong together.
One concrete example is the data quality of artifacts. In a project with SAFe as a framework, we measured whether stories were complete: Was a specialist application selected, are acceptance criteria in place, are the fields filled in correctly. The result: 60 percent of the tickets were incomplete.
Gaps made visible change behavior. As soon as the team saw the number, the quality of the tickets increased and simple errors and returns decreased. A good indicator is also whether the numbers match your gut feeling. If the data says disaster while everything feels good, something is wrong.
Why quality by design is not a framework like Scrum
Quality by Design does not prescribe fixed processes. It is not a framework that makes rules, but an approach that works with the team to find its own weak points.
The core is the risk analysis at team level. You look at where things can go wrong, for example because a technology is new and unknown, and define a measure right there. Test-driven development can be a suitable approach, but it doesn’t have to be. The measure must fit the team.
The team size determines the necessary level of rules. A small team of two or three senior people needs fewer rules than a structure consisting of several teams with juniors who are not yet familiar with the business.
The success factor is not to impose anything blindly. Measures that the team is willing and able to implement themselves stick. Not imposed rules.
Quality is an attitude, not a tick box fulfillment
Compliance is not the same as quality. Meeting specifications and regulations does not mean delivering good quality. This fallacy exists in both pharma and software.
Quality begins with the question of who is responsible for it. The answer: every single person. In the pharmaceutical industry, a question posed to employees makes this tangible.
Would you inject this medicine into a child? That is quality.
Thomas Gsponer
Applied to other products: Would you get on the plane whose controls you programmed? This attitude only works if the whole company shares the same quality culture.
If the culture is there, people will go to great lengths to get there. They make suggestions for improvement of their own accord. Then quality by design becomes a matter of course. This point is not easy to achieve.
How to get started with Quality by Design without getting bogged down
Start small and don’t build a large QBD construct right from the start. That wouldn’t work. The starting point is the target profile with the user requirements.
From there, a list of influencing variables quickly emerges where developers say something could go wrong. From this, you ask what this means for the developer, end user, product and company. This will give you a few key figures to start with.
The following applies to the measuring points: as few as possible, only at the really critical points. It’s better to have four key figures that you understand than many that nobody evaluates.
As soon as data is generated, there will be fluctuations. The next step is to understand this variability and find its influencing factors. With this improvement mindset, more sophisticated metrics will emerge on their own over time.
Transformation takes time. It takes one to two years for the first effects to take effect because it is a cultural change. You start everywhere at the same time, but in small steps.
Removing complexity is often the quickest win
Quick wins are often found where processes have accumulated tools over the years. If something doesn’t work, you build another piece of software on top of it and end up moving data back and forth between tools.
An example from a project with several hundred participants: stories were collected over several sprints in Jira, then exported to Excel, sorted there and approved via a SharePoint. There were also technical problems.
The solution was to do the acceptance directly in Jira, without exporting. The workflow and authorizations were adapted for this. The acceptance process ran faster, the overview was immediately available and project managers could see directly on the board what was working and what was not.
The introduction initially caused friction because established processes had to change. Afterwards, the feedback was good and the time saved was used elsewhere. People who are in the middle of their work and have to deliver often don’t see such simplifications themselves.
Think first, then develop
Continuous integration and continuous deployment make it easy to deploy without thinking. It is delivered continuously, and because there is enough computing power, nobody has to think too much about what will come out. If something goes wrong, a bug is fixed afterwards.
AI-supported tools reinforce this temptation. Code can be generated quickly, the pipeline sends it through the world, automated testers run along with it. Often, no one knows for sure whether these tests will find any bugs at all.
The greatest leverage therefore lies in thinking first, then developing. Use the user requirements to check whether the feature is really needed and build it in such a way that it comes out right the first time.
Then there is the resource aspect. Blindly developing or automating new software consumes resources that are not actually needed. Regularly scrutinizing the process to see what is needed and what is not is part of quality by design.
