软件开发有一个传说，越早发现问题最后产品的质量越有保障。软件开发中保障质量的主要方法有两个，Code Review 和测试。然而 Code Review 通常在代码已经大致成型之后，而测试又在更靠后的阶段，那么在看似事后的手段中投入大量精力来保证软件质量是不是本末倒置呢？
这些看似不合理的流程的设立其实有着更深层面的原因，如果一个人身体是车床，技术是工艺流程，软件是车床上的产品，那么人和机器有什么区别呢？人不是完美的，人会犯错误，人有着复杂的心理变化，这些心理起伏会对整个结果产生影响。
一个简单的例子，如果开发的流程引入了 Code Review 和测试，写代码的人就会写的更加小心。我们对看不见的客户碰到问题而抱怨可以视而不见，但被身边的人指出来你这里有问题就心里亚历山大，为了避免这种窘境就需要在写代码过程中注意这里会不会被人揪出问题。所以这些看似后期的流程会在前期就发生巨大的作用，甚至他们最大的作用其实并不在测试过程中发现了多少问题，而在于有测试这件事对开发过程产生的心理影响。
车床上的产品在流入市场前也会经过测试，软件测试和这种测试还有一些微妙的区别，由于软件产品和人是直接相关的，而这种测试也不可避免的把人加进来，把人加入这个流程事情就复杂了。当找到一个 bug 如果交给机器人处理，机器会按照预订路线处理。而如果是人本能反应会是抗拒的，尽管指出的是软件的问题，而负责人产生的心理反应会是他觉得我有问题，我是不是很糟糕等一系列负面情绪，于是接下来本能的反应就是回避掉或者转移这个问题，诸如在我的机器上是好的呀，我测过没问题呀，我没有动过这块呀，是不是别的组件有问题呀，这个就是这样的不是问题……这样面对 bug 的惯用句式。
同样由于测试也是人，这种抗拒的答复又会在测试的人身上产生反应，认为是对自己测试工作的否定，而接下来的反应很可能就连锁循环下去了。日积月累下来，测试和开发的关系可能就不会太好了，本来双方的理想工作模型是以软件作为中介互相配合，到最后变为相互间直接的指责。这种相互指责其实还不是最差的结果，另一种可能就是双方都是和气的人不想惹对方生气，开发想万一让他们测出问题来他们又得嫌弃我了，我这个功能不告诉他们偷偷上好了，测试发现问题想这个问题好想也不太严重不会影响客户吧，告诉开发他可能心情不好，觉得我事多，要不就算了吧。这样表面的和和气气下隐藏着更大的危险。
仔细想想这些事，发现软件的质量还真不只是技术的问题，心理层面的问题会起着微妙而又举足轻重的作用，而如果开发和测试双方都能意识到这点，能跳出自己的心理定式，客观的看待软件中的 bug，了解对方反应背后的心心理动机，多一些理解，那么整个流程的效率就会更高，软件的质量也能得到更好的保证。
当然这些想法都是我在读《颠覆完美软件-软件测试必须知道的几件事中》想到的，推荐开发和测试还有基础团队的领导者抽空看一看。这是本顶着测试的名号讲程序开发心理学的书，里面会有些更有意思的例子，读过后会有很多旁观者清的体会，也会更深刻的理解那些技术表面下的心理本能。
我在读《颠覆完美软件-软件测试必须知道的几件事中》想到的，推荐开发和测试还有基础团队的领导者抽空看一看。这是本顶着测试的名号讲程序开发心理学的书，读过后会有很多旁观者清的体会，也会更深刻的理解那些技术表面下的心理本能。