Note: You can find the English version after the Chinese one.
—— 《质量免费》 【美】菲利浦·克劳士比
Scenario One: Limited Budget and Quality Improvement
"Writing automated unit tests and end-to-end tests requires more money, but our budget is limited, so we can't implement them for now."
"We've configured SonarQube scans on our CI, but we don't have the budget to fix the issues it finds. This initiative is currently not feasible."
In the course of advancing a series of quality improvement initiatives, an IT team often hears such voices. Many initiatives cannot be implemented due to the constraint of limited budget. This seems to be a dilemma troubling many teams because vendors often demand additional fees to support automation testing and security vulnerability fixes.
The core issue of this dilemma lies in the fact that limited budget appears to be the primary obstacle hindering teams from enhancing quality. In reality, it is crucial to fully understand the investment in quality improvement: it involves both short-term expenditures and, more importantly, long-term investment.
In the short term, fixing existing code bugs, addressing security vulnerabilities, or supplementing automated testing in cases where it is lacking, indeed requires additional investment, as it falls outside the scope of new feature development. However, fixing code vulnerabilities can enhance the overall quality of the code, and automated testing can provide fast feedback on code changes, effectively ensuring software quality. In the long run, the benefits of these initiatives outweigh the short-term investment.
Scenario Two: Business Pressure and Quality Trade-offs
"Our business team is too dominant, and once the release date is set, it puts immense pressure on us. We are completely deadline-driven, with tight delivery timelines that must meet the final deadline, making it challenging to ensure quality."
"We want to negotiate with the business team, telling them that to ensure quality, they need to give us enough time and resources. However, the business team believes that the market competition is too intense, and once the release date is set, it cannot be changed. They insist on compressing our time while also demanding quality assurance."
This is how an IT delivery team describes their situation, feeling quite helpless. In such circumstances, teams often feel compelled to make choices between time and quality, resulting in inadequate quality assurance.
Is fast delivery truly contradictory to high quality? Not necessarily. Fast delivery and high quality can coexist harmoniously. By employing a reasonable development process, adopting an iterative development approach, controlling quality from the source of requirements, and ensuring fast feedback at each stage to achieve defect prevention, it is possible to achieve both fast delivery in the short term and sustained high quality in the long term.
Of course, demanding too many features in an overly short time frame is unrealistic, especially in situations where requirements are not clearly defined and require continuous clarification by the development team. Therefore, IT teams responsible for delivery need to adopt appropriate strategies to communicate with the business team.
IT and the business team should serve the same business goals and not be in opposition due to conflicting interests. It is not about saying, "If you don't give me more time, I can't deliver a higher quality product," but rather about strengthening communication and collaboration. IT needs to align with the business goals, consider how to maximize the delivery of business value based on those goals, and ensure quality. This may involve reevaluating requirements, prioritizing value, adjusting schedules appropriately, and optimizing control over requirement quality.
Quality is Free
The book "" by American management guru Philip B. Crosby, published in 1979, is hailed as the Bible of the quality revolution. Although the book is relatively old and primarily focuses on the quality of industrial manufacturing, its core ideas remain applicable to today's software delivery: striving for zero defects, getting things right the first time, and recognizing that quality is not only free but can also reduce costs in the long run.
Zero Defects Philosophy
The essence of the zero defects philosophy is an attitude of defect prevention, meaning "getting the job done right the first time."
— From "Quality is Free" by Philip B. Crosby
Software delivery is indeed more complex than industrial manufacturing, and today's software ecosystem involves many uncertainties. However, we can still adopt a mindset of pursuing zero defects when developing software, emphasizing defect prevention, and reducing rework waste.
Some may recall that when I talked about what quality is, I mentioned, "Quality is not zero defects, not..., not...". Why am I now talking about pursuing zero defects? The meanings conveyed by these two statements are distinct.
❌Quality is not zero defects, not 100% test coverage, and not the absence of technical debt.
✅Quality is fast feedback, ensuring that any change can be quickly verified and repaired.
✅Quality is focusing energy on the right things.
✅Quality is a team having confidence in making changes to code, design, and delivery.
✅Quality is a team taking responsibility for any changes.
1. Differences in Quality Requirements for Software and Hardware
The concept of "zero defects" mentioned in "Quality is Free" is applied to hardware manufacturing. We are aware that hardware quality generally demands higher standards compared to most software quality requirements. A defect in a component of a hardware product may potentially render the entire hardware product non-functional. In contrast, software products may allow certain non-critical functions to have defects and still go live, as long as they meet user needs.
2. Quality is Not Zero Defects
Quality is not zero defects, meaning that software quality should not blindly pursue a defect-free state. Instead, it should be considered in conjunction with business goals, aligning with business requirements and satisfying user needs. Of course, there are corresponding non-functional requirements that also need to be met. In essence, software quality should be driven by business value, striving for an optimal balance.
3. Pursuing Zero Defects in Software Development
Although "zero defects" originated from the hardware manufacturing industry, its emphasis lies in the key concept of getting things right the first time. The frequently mentioned concept of "quality built-in" underscores defect prevention, striving to do well in every phase and embedding quality into the software product. This aligns seamlessly with the philosophy of zero defects.
"Getting It Right the First Time" in Software Development
Crosby introduced the concept of quality cost in "Quality is Free," emphasizing the importance of preventing quality issues. He believed that the costs incurred in preventing and correcting quality issues are "free" because they are negligible compared to the losses caused by quality problems.
The cost difference at various stages is evident in the change cost curve shown below:
Therefore, if things can be done right the first time, achieving defect prevention, quality not only becomes free but can ultimately reduce quality costs.
Of course, perfection is elusive, coupled with the complexity of software development. It is impractical to expect everyone at every stage to get things right the first time, which is why I placed "getting it right the first time" in quotes in the previous heading. We believe that "quality built-in" does not strictly mean no defects exposed; instead, it involves getting things right early in the software development lifecycle and making continuous adjustments and improvements through obtaining fast feedback.
Quality built-in can be understood as executing the PDCA cycle frequently throughout the software development lifecycle, from requirements to production, taking small steps forward, continuously validating feedback, and promptly adjusting for improvement, as illustrated in the diagram below:
Quality Built-in Practices in the Software Industry
The core of quality built-in mainly involves four aspects: shift-left testing, shift-right testing, fast feedback, and collective responsibility. Key practices corresponding to these aspects include (but are not limited to) the following:
Note: The text in the image is in Chinese, but you can find the English version of the image explanation here.
Leading internet and technology companies at the forefront, such as Google, Amazon, and Facebook, have implemented these quality-built practices more effectively through end-to-end standardization and extensive automation. This has resulted in significant improvements in the quality and efficiency of software delivery.
Zero defects mean striving to get things right and achieving defect prevention as much as possible. The zero defects philosophy in the software industry does not blindly pursue a defect-free state but emphasizes quality built-in to achieve an optimal level of quality.
Getting things right from the start makes quality free. Many believe that quality is not free because there are already debts, and money needs to be spent to repay them.
IT delivery teams need to align with business goals, strengthen communication and collaboration, control quality from the source of requirements, and jointly pursue a balance between quality and efficiency to achieve the delivery of maximum value.
- "" by Philip B. Crosby
- Everyone Is Responsible For Quality
- The Core of Agile Testing
- Building Systematic Thinking for Testing (Intermediate)
- Agile Team's Quality Enablement
- Business Value Driven Testing