首先明确，质量是测试不出来的。有个比喻很有意思：不能通过反复测试来提高质量，这就好像你不能通过反复称重来减肥一样。
在Google，质量不等于测试，有些公司则不然。“质量不能通过测试而植入”这个是老生常谈了，我们不必去怀疑他的正确性。从手机到软件，如果你没有在一开始就把它构建好，那么他永远不会正确的工作。如果你不知道一开始不重视质量的代价，那么去问问陷入“召回门”的汽车厂吧。
“质量不能通过测试而植入”这话本身并不通俗，它也不是一个准确的描述。可是为什么这么说？因为显然，如果没有测试你不可能开发出什么高质量的东西。对啊，如果你不测试，你怎么知道你开发出来的东西就是高质量的呢？
解决这个问题的简单方法就是不要把开发和测试当做两个单独的学科。测试和开发应该是起头并进的——写一点、测一点；写一坨，测一坨。更好的方法是，在你写代码的时候就准备如何测试，甚至是在写代码之前。测试并不是一类单独实践艺术，他是开发过程的一个部分。质量不等于测试，好的质量是通过把开发和测试有机粘合在一起来实现的，以致你不能区分出对方。
上面的描述就是我们在Google的目标：合并开发和测试直到你不能在没有其中一个的时候完成另外一个。构建一尺，测试一尺；构建一丈，测试一丈。这里的关键问题是：谁来做这个测试。鉴于Google中全职的测试工程师从比例上来讲少得可怜，那么答案自然是开发工程师。有谁比代码的编写者自己来做测试更合适呢？有谁比他自己来发现bug更合适呢？谁会对能在第一时间避免bug更振奋呢？Google之所以能够在测试工程师这么少的情况下还能这么得瑟，就是因为开发对质量负责。事实上，坚持保留一个大量测试的团队通常被认为是在犯错。保有一个大型测试团队是“开发工作/测试工作”严重失衡的标志，增加更多的专职测试人员是不会解决问题的。
换句话说：质量保证是重预防而不是重检测。质量保证是一个开发问题，而不是一个测试问题。通过“把测试签入到开发中”，我们建立了一个“超增量”的过程，能做到“当一个改动导致错误太多，那么就会自动回滚”。我们不单是避免了很多用户问题，而且大幅降低了用来确保“没有recall-class bug”的测试工程师的数量。在Google，测试的目的就是发现这种“避免问题”的方式是不是做的足够好。TE时刻会关注SWE-SET的这种组合是不是能达到“避免用户问题”的目的，一旦流程出现了问题TE就会发出警告。
团队的各种迹象都能体现这种测试和开发的融合，从code review中的“你的测试呢”到厕所中大幅海报提醒开发者采纳最佳的测试实践——臭名昭著的“Testing On The Toilet”提示。测试必须成为开发不可回避的一面，开发和测试的联姻的那天就是质量能够得到保证的那天。SWE是测试工程师，SET是测试工程师，TE也是测试工程师。
如果你的组织也在做这种融合，何不分享你的成功和挑战呢？如果你们的组织不在尝试这种融合，那么这是你们组织可以尝试的一个变化：让开发工程师全权承担起质量的任务。有句谚语说得好chickens are happy to contribute to a bacon and egg breakfast but the pig is fully committed（意思是说，鸡愿意为“鸡蛋咸肉”早餐贡献一份力量，而猪不愿意。因为鸡只是提供了鸡蛋，自己毫发无损，而猪却把自己都押上了。其实就是说要把开发置于死地而后生，让他们自己测）。这样一来你如果发现你的开发工程师发出猪的叫声这就ok了，如果他们发出鸡的叫声那就有问题了。
