开放的测试

在大多数公司里面，开发和测试似乎就是天生对头。很多开发和测试也都这么认为，甚至一些公司从制度上就这么设计的。就像古代一个轶事：某人筑新城，工匠筑完后，使人以大锤砸之，砸得坑则杀匠人，砸不动则杀使锤者。但从团队角度，无论是开发还是测试，共同目标不是确保产品成功吗？两者的利益并没有对立，这样对立起来对团队有好处吗？

记得Google有个说法，Bug在开发中发现并修改，5美元；在测试后发现并修改，50美元；上线后发现并修改500美元；那么从成本角度，我们应该尽量在开发中发现并修改，这样对产品最有利。那么我们如何尽量做到在开发中发现问题并修改呢？如果鼓励开发和测试对立，比如测试以缺陷发现多作为优胜，那么测试就尽可能不告诉开发他要怎么测试，并期望在这个Hide&Seek游戏中找到开发的把柄。并且每找到一个问题都会非常兴奋，因为这对他绩效有利。然而这些问题我们都是要花10倍于开发时的代价去解决，很显然这么做对产品和团队是没有什么好处的。

那么如何在统一测试和开发共同目标后，如何做到降低开发成本呢？测试不应该以发现缺陷为荣，而是应该以如何协助开发完成没有缺陷的产品为荣。如果产品没有缺陷或者很少，这不仅仅是开发的光荣，也是测试的光荣。要做到这一点，就需要改变以前测试和开发的工作方式。

在Scrum的5个价值观中，其中一个是“开放”。在Team内部没有秘密，所有资讯都是开放的。那么对开发来说，测试要如何测试，也是没有秘密的。因此，在开发的时候，测试和开发一起制定测试方案。可以在UserStory上以检查项形式来编写如何对UserStory进行测试，这个检查项包含了测试所有需要对UserStory进行测试的路径。开发人员严格按照检查项进行开发，并在自己的集成测试中，严格测试每一个检查项，确保自己开发的软件，符合测试和产品的期望。

经过这样的过程后，可能仍然有缺陷发生。那么测试需要统计一个数据：1、应该能写到检查项而未写的 2、写了检查项但开发没有测试的 3、其他。对于1，2，我们应该尽量设法避免。这样就可以最大化减少我们开发的成本，以及发生缺陷的几率。