“嗯，是这样的。”
“那么你就把提交代码的质量要求提高到一个地步，就是必须全部通过一个主要应用场景的各个步骤。我们可以达到这个地步，但实际上并不需要达到这个地步。”
“提高质量要求不是更好吗？”（见作者注1）
“较次要的功能如果为了准时发布或者达到商业竞争的目的，完全是可以牺牲的，也就是说有可能为实现其他更重要的功能而削掉它。那么你在每次提交都要执行的测试里面去检验这个步骤能否通过，显然没有必要，而且迫使每一个开发人员随时关注这个功能，以及为了提交成功一直照顾这个功能。”
“哦，我懂了。像阿德的代码并不涉及和依赖这个功能，但是他每次提交代码都得确保这个步骤没错，其实没有必要。”
“那认输不认输？”
“我……我要搞明白一个问题，怎样找到不重要的步骤呢？我总是下意识的按着功能说明走。”
领导拉过一个白板，在上面画了一些大写字母并且用箭头连接起来。
“你提到依赖，这很好。看看这些字母代表各个步骤或者子功能，有些步骤取决于另外一些步骤，举个例子，记事本程序的显示文本文件内容功能依赖于文本文件打开功能。我用箭头表示依赖关系，A指向B表示A依赖B；没箭头的线则表示谁先谁后没有关系。
“有些步骤是相当重要的，例如记事本程序的保存功能，写半天字没法保存，是严重的数据丢失问题。我在这些代表重要步骤的字母上画个圈。
“重要的步骤，也就是画圈的步骤，加上它们所直接和间接依赖的所有步骤，也就是从圈开始顺着箭头走遍的所有步骤。其它的步骤都是不重要的，不需要出现在保证提交质量的测试中。如果一个步骤后来被认为是重要的，可以，在这个图上面再走一次。”
“我请你吃饭好了，老大。”大毛说。
作者注：如果有开发人员明明测试通不过，还是要提交代码，这往往是开发和测试团队结下矛盾的开始。先不要激动，听听开发人员怎么说，如果是埋怨通不过的步骤，可以尝试一下依赖图的方法，并且和开发人员分享这个依赖图。因为高标准严要求，不见得是合适的。工程问题要用工程方法解决，不要用哲学方法解决。
作者注1：这个理由可是通杀四方的大道理，谁遇上它都无言以对。只是照这个逻辑，所有测试，——包括整合、性能、可靠性、压力……全部家当加起来都通过才能提交，岂不是最高的质量标准？那质量一定很好了吧？实际上，这样做的话，没人能够顺利提交，或者要花大量时间才能提交。没有做完的产品，或者没法按时做完的产品，何来质量可言？
相关链接：
