撰写Note: You can find the English version after the Chinese one.
两个场景
场景一：有限经费与质量改进
“要写自动化的单元测试、E2E测试，就会需要更多的钱，可是我们经费有限暂时做不了。”
“CI上配置SonarQube扫描，对于扫描出来的问题我们也没有经费修复，这个举措也是没法实现。”
……
某IT团队在推进质量改进系列举措的时候总能听到这样的声音，就是由于经费有限很多的举措都实施不了。这似乎成为了一个困扰许多团队的难题，因为供应商往往要求额外费用来支持自动化测试和安全漏洞修复等。
这种困境的核心问题在于，有限的经费似乎成为阻碍团队提高质量的主要障碍。其实，需要全面理解质量改进的投入：质量改进是一项短期支出，更是一项长期的投资。
短期内去修复已有的代码Bug、安全漏洞，或者在原本没有自动化测试的情况下去增补自动化测试，确实需要额外的投入，因为这不属于新功能开发部分的工作内容。但是，代码漏洞的修复可以提高代码整体质量，而自动化测试能对代码改动提供快速反馈，能更有效地保障软件的质量。从长远来看，这些举措的收益都是大于短期投资的。
场景二：业务压力与质量折扣
“我们业务方太强势，上线日期定了以后给到我们很大压力，我们完全是Deadline驱动，交付时间很紧，得满足最后期限，很难保障质量。”
“我们想跟业务方交涉，要保障质量他们得让我们有足够的时间和投入，但是业务方认为市场竞争太激烈，上线日期定了就不能动了，只能压缩我们的时间，同时也要求我们保障质量。”
某IT交付团队如此描述他们的现状，感觉很无助。这种情况下，团队往往感到被迫在时间和质量之间做出抉择，导致质量无法得到充分保障。
快速交付和高质量真的是矛盾的吗？其实不然，快速交付和高质量是完全可以和谐共存的。 通过合理的开发流程，小步迭代式开发，从需求源头开始把控质量，在每个环节做到快速反馈，实现缺陷预防，既可以做到短期内快速交付，也可以长期内保持高质量。
当然，过短的时间内要求开发过多的功能确实也是不现实的，尤其是需求都没有清晰描述还需要开发团队不断去澄清的情况。因此，负责交付的IT团队需要采取合适的策略跟业务方进行沟通。
IT跟业务方应该是同样服务于业务目标的，不应该是利益冲突的对立方，不能说“你不给我更多的时间我就没法交付更高质量的产品”，而是需要加强沟通与合作。IT需要跟业务方对齐业务目标，基于业务目标，考虑如何最大化业务价值的交付，并且能保障质量。 这就可能涉及到对需求重新梳理，进行价值排序，调整合适排期，对需求质量的把控等一系列的优化。
质量免费
美国管理学家菲利浦·克劳士比于1979年出版的书籍《质量免费（Quality is free）》被誉为质量革命的圣经，是管理学的经典名著，中文版也于2011年面市。虽然书的年代比较久远，且内容主要关于工业制造的质量，但核心思想对今天的软件交付一样是适用的：追求零缺陷，一次性把事情做对，质量不仅是免费的，长远来看能降低成本。
零缺陷理念
零缺陷的要旨是预防缺陷的态度，它的意思就是“第一次就把工作做对”，如此而已。
—— 《质量免费》 【美】菲利浦·克劳士比
软件交付确实比工业制造要复杂得多，而且今天的软件生态也存在居多不确定性因素，但我们同样可以以追求零缺陷的心态去开发软件，做好缺陷预防工作，减少返工浪费。
可能有朋友会记得我在讲质量是什么的时候提到过“质量不是零缺陷，不是…，不是…”，为什么现在我又提到要追求零缺陷呢？这两者表达的含义是有区别的。
1. 软硬件质量要求的差异
《质量免费》中提到的“零缺陷”是针对硬件制造来说的，我们知道硬件质量通常比绝大多数的软件质量要求要高，硬件产品中的某个零配件如果有缺陷有可能导致整个硬件产品不工作，而软件产品对于某些不是那么关键的功能甚至是可以允许带着缺陷上线的，只要能满足用户使用即可。
2. 质量不是零缺陷
质量不是零缺陷，意思是软件质量不能一味追求没有缺陷，而是要结合业务目标考虑，符合业务需求、能满足用户使用，当然，也会有相应的非功能需求需要满足。总之，软件质量要以业务价值驱动，只需做到恰到好处。
3. 软件开发也需要追求零缺陷
“零缺陷”虽然是从硬件制造行业提出，但其强调的是一次性把事情做对的关键理念。我们经常提到的质量内建就是强调的缺陷预防，在每个环节都尽量做好，将质量内建到软件产品中，这跟零缺陷理念是完全契合的。
软件开发中的“一次性”把事情做对
克劳士比在《质量免费》中提出了质量成本的概念，强调了预防质量问题的重要性。他认为花费在预防和纠正质量问题上的成本是“免费”的，因为这些成本相比于质量问题导致的损失来说是微不足道的。
我们从下图的变更成本曲线图也能清晰看到不同阶段成本的差异：
因此，如果能一次性把事情做对，实现缺陷预防，质量不仅是免费的，最终还是可以降低质量成本的。
当然，人无完人，加上软件开发的复杂性，要求所有人所有环节都能一次性把事情做对显然是不现实的，这也是我前面标题中给“一次性”加引号的原因。我们认为，质量内建并不是严格意义上的不能有任何缺陷暴露，而是需要在软件开发生命周期中尽早地把事情做对，并且通过持续的获取快速的反馈来纠偏。
质量内建可以理解为在软件开发全生命周期中，从需求到线上频繁地执行PDCA环，小步前进，持续反馈验证，及时调整改进。如下图所示：
软件行业质量内建相关实践
质量内建的核心主要有测试左移、测试右移、快速反馈和全员负责四个方面，对应的典型实践通常有（不限于）以下这些：
一些前沿的互联网科技公司，比如Google、Amazon和Facebook等，通过全流程的标准化和大规模的自动化将这些质量内建实践实施的更为到位，软件交付的质量和效能都得到了很大的提升。
（PS：思维导图原图可从网页顶端菜单栏【资源下载】页面下载，或点击此链接进入资源下载页面。）
总结
零缺陷就是要求尽可能把事情做对，实现缺陷的预防。软件行业的零缺陷理念不是一味追求没有缺陷，而是要做好质量内建，将质量做到恰到好处。
从头开始一次性把事情做对，质量就是免费的。很多人认为质量不是免费的，那是因为已经欠债了，需要花钱去还。
IT交付团队要跟业务方对齐业务目标，加强沟通与协作，从需求源头把控质量，共同追求质量和效率的平衡，以实现最大价值的交付。
【推荐阅读】
- 《质量免费（Quality is free）》，【美】菲利浦·克劳士比
- 团队为质量负责
- 敏捷测试的核心
- 构建测试的体系化思维（进阶篇）
- 敏捷团队的质量保障赋能
- 业务价值驱动的测试
- Google、Amazon和Facebook的质量内建实践思维导图
English Version
Two Scenarios
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 "Quality Is Free: The Art of Making Quality Certain" 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.
(Note: The original mind map can be downloaded from the top menu bar of the "Resources Download" page on my blog website, or you can click on this link to access the resources download page.)
Summary
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.
Recommended Reading
- "Quality Is Free: The Art of Making Quality Certain" 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
This article was originally published on the personal website "BY林子", for reprints, please refer to the copyright statement.