Quality by Design (QbD) is an approach that secures software quality through the way the development process itself is designed, rather than through testing at the end. The aim is to keep defects from arising in the first place. That means analyzing risks in the process, defining measurable quality characteristics and steering the process continuously with concrete metrics.
Key Takeaways
- Preventing defects costs less than finding and fixing them through testing. Quality by Design shapes the development process so that quality is built in rather than checked afterwards.
- Software quality and source code quality are two different things: one describes the value for the user, the other the measurable quality of the code, and each needs its own metrics and measures.
- Teams that don’t check artifacts such as user stories for completeness are building on shaky ground. In one project, sixty percent of the tickets were incomplete, which led to misinterpretation and unnecessary rework loops.
- Quality by Design is not a framework you install but a cultural change. Everyone on the team is responsible for quality, and that attitude grows from a shared understanding of what is at stake, not from rules.
- When you introduce metrics, start with a few targeted measuring points at the truly critical spots and monitor them consistently, instead of building a full KPI system from day one.
Quality by Design in Software Builds Quality In from the Start
Quality by design software development builds the process so that defects never get in, instead of hunting them down and removing them later. The approach comes from the pharmaceutical industry and carries over well to software development.
Many companies treat quality and testing as the same thing. Testing matters, but it only kicks in once the defect is already in the product. Alessandro Sebaste puts the basic problem plainly: you produce defects so that you can search for them and remove them again. It would be smarter not to produce them at all.
That is the difference between quality by design and quality by testing. The focus moves from testing the end product to the process that creates it. In pharma, that is the manufacturing process. In software, it is the software development process.
How Quality by Design Works in the Pharmaceutical Industry
In pharma, everything starts with a Quality Target Product Profile, or QTPP. It holds the user requirements for a medicine: it has to be safe, it has to work, people have to be able to afford it, and today sustainability is part of the list as well.
From this target profile you derive the critical quality attributes that can be measured during manufacturing. At the same time, you keep asking what could go wrong in the process so that this quality is not reached. A risk analysis serves this purpose.
The process is then designed so that it is measured and controlled continuously. Thomas Gsponer sums up the goal: defects are not built into the product, and less testing of the end product is needed.
The approach rests on two pillars. The first is risk analysis, the second is continued improvement. Both apply to software just as much as to a medicine.
Software Quality and Source Code Quality Are Not the Same
If you want to steer quality, you have to separate software quality from source code quality. They have a different focus and need different measures.
Software quality shows in the characteristics users experience. Software should run stably, perform well and be easy to use. An application’s power consumption is increasingly becoming a customer requirement too. The guiding question is: what does the customer need, and what does the customer’s customer need?
Source code quality is the level below. It is about the building blocks the solution is made of.
This leads to a nuanced stance on agility. How an application is built should stay open. When it comes to the components you use, fewer compromises make sense. When writing code, fixed rules apply up to a certain point, and beyond it the team is free to be flexible.
Metrics Only When They Lead to Decisions
A metric is only worth something if someone derives a change from it. Many teams let a tool spit out numbers and never use them to understand where things go wrong and what could be improved.
Quality by Design flips that relationship. You don’t change things on gut feeling but on the basis of data. Measuring, understanding and targeted intervention belong together.
One concrete example is the data quality of artifacts. In a project using SAFe as its framework, the team measured whether stories were complete: had a business application been selected, were acceptance criteria in place, were the fields filled in correctly? The result: 60 percent of the tickets were incomplete.
Gaps that become visible change behavior. As soon as the team saw the number, ticket quality went up, and simple mistakes and returned tickets went down. Another good indicator is whether the numbers match your gut feeling. If the data says disaster while everything feels fine, something is off.
Why Quality by Design Is Not a Framework Like Scrum
Quality by Design doesn’t prescribe fixed procedures. It is not a framework that sets rules but an approach that works with the team to find its own weak spots.
At its core is risk analysis at team level. You look at where things could go wrong, for example because a technology is new and unfamiliar, and define a measure right there. Test-driven development can be a good fit, but it doesn’t have to be. The measure has to suit the team.
Team size determines how many rules are needed. A small team of two or three senior people needs fewer rules than a setup of several teams with juniors who don’t know the business yet.
Success depends on not imposing anything blindly. Measures the team wants to implement, and is able to, will stick. Rules imposed from outside won’t.
Quality Is an Attitude, Not a Box-Ticking Exercise
Compliance is not the same as quality. Meeting specifications and regulations doesn’t mean you deliver good quality. That fallacy exists in pharma as much as in software.
Quality starts with the question of who is responsible for it. The answer: every single person. In pharma, one question put to employees makes this tangible.
“Would you inject this medicine into a child? That is quality.”
(Thomas Gsponer)
Applied to other products: would you board the plane whose controls you programmed? That inner attitude only holds if the whole company shares the same quality culture.
Once that culture exists, people go to real lengths to get there. They come up with improvement ideas on their own. Then Quality by Design starts to run by itself. Reaching that point is not easy.
How to Get Started with Quality by Design Without Getting Bogged Down
Start small, and don’t build a big QbD construct from the outset. It wouldn’t work. The entry point is the target profile with the user requirements.
From there, a list of influencing factors quickly emerges: places where developers say something could go wrong. For each, ask what it means for the developer, the end user, the product and the company. That gives you the few metrics you start with.
For measuring points, the rule is: as few as possible, and only at the truly critical spots. Four metrics you understand beat many that nobody analyzes.
As soon as data comes in, you will see fluctuations. The next step is to understand that variability and find what drives it. With this improvement mindset, more refined metrics emerge by themselves over time.
A transformation takes time. It takes one to two years before the first effects show, because it is a cultural change. You start everywhere at once, but in small steps.
Removing Complexity Is Often the Quickest Win
Quick wins are often found where processes have piled up tools over the years. When something doesn’t work, another piece of software goes on top, and in the end people shuffle data back and forth between tools.
An example from a project with several hundred people: stories were collected in Jira over several sprints, then exported to Excel, sorted there and approved through SharePoint. On top of that came technical problems.
The fix was to do the acceptance directly in Jira, with no export. The workflow and permissions were adjusted for it. Acceptance ran faster, the overview was there immediately, and project managers could see on the board what was working and what wasn’t.
The change caused friction at first, because established routines had to change. Afterwards the feedback was good, and the time saved went into other work. People in the middle of their work who have to deliver often don’t see simplifications like this themselves.
Think First, Then Develop
Continuous integration and continuous deployment make it easy to deploy without thinking. Delivery runs constantly, and since there is plenty of computing power, nobody has to think hard about what comes out. If something breaks, a bug gets fixed afterwards.
AI-assisted tools make that temptation stronger. Code can be generated quickly, the pipeline pushes it out into the world, automated tests run along. Often nobody knows anymore whether those tests would even find a defect.
The biggest lever therefore sits before all that: think first, then develop. Use the user requirements to check whether the feature is really needed, and build it so that it comes out right the first time.
Then there is the resource side. Blindly developing or automating new software uses up resources that aren’t actually needed. Regularly questioning the process, what is needed and what isn’t, is part of Quality by Design.
Frequently Asked Questions
Is testing enough to ensure software quality?
No. Testing only comes into play once a bug is already present in the product. In other words, you create bugs just to find and fix them later. Quality by Design starts one step earlier: The development process itself is designed so that bugs don’t arise in the first place. The focus shifts from testing the final product to the process that produces it.
Can a quality approach from the pharmaceutical industry be applied to software?
Yes, because the core elements are identical. In the pharmaceutical industry, the process begins with a target profile outlining user requirements; from this, measurable critical quality characteristics are derived, and the manufacturing process is continuously monitored. In software, the development process takes the place of the manufacturing process. The two pillars remain the same: risk analysis and continuous improvement.
Why should software quality and source code quality be considered separately?
They have different focuses and require different measures. Software quality describes the user’s experience: stability, performance, usability, and increasingly, an application’s power consumption. Source code quality lies one level below and concerns the building blocks of the solution. The key question for the upper level is: What does the customer need, and what does the customer’s customer need?
What are the benefits of measuring the completeness of user stories?
Gaps that are made visible change behavior. In a project using SAFe, checks were performed to verify whether a business application had been selected, whether acceptance criteria were in place, and whether the fields had been filled out correctly. Sixty percent of the tickets were incomplete. As soon as the team saw this figure, ticket quality improved, and simple errors and rework decreased.
Does every development team need the same quality rules?
No. Team size and experience determine the necessary level of rules. A small team of two or three senior members can get by with fewer guidelines than a structure comprising multiple teams with junior members who are not yet familiar with the business. Practices like test-driven development may be appropriate, but they aren’t necessarily so. Rules imposed from above don’t stick.
Does compliance automatically mean good quality?
No, that’s a common fallacy, in both the pharmaceutical and software industries. Meeting specifications and regulatory requirements does not necessarily mean delivering good quality. Quality depends on the attitude of each individual. Thomas Gsponer makes this tangible with a question: Would you inject this medication into a child? To put it another way: Would you board the airplane whose flight controls you programmed?
How long does it take for a quality approach like Quality by Design to take effect?
It takes one to two years to see the first results, because this is a cultural shift and not just a framework you implement. The rollout begins everywhere at the same time, but in small steps: first, the target profile with user requirements, then a few key metrics at critical points. It’s better to have four metrics that are well understood than many that no one analyzes.
