11年华为工作经历中印象深刻的事情

　　蔡：在一家公司能持续工作11年，挺不容易的。在这11年里，有哪些给你留下深刻印象的项目或者事情呢？

　　测试并不只是发现bug

　　邰：这方面的事情自然很多，我举个例子吧。大概在2005年的时候，我带一个测试组做一个小型产品的测试。这款产品的主要功能是配置和维护，功能并不算复杂，但是是新开发的产品，从零做起。我们测试组有十几个人，大家的干劲都比较高。这是我第一次独立带团队做测试，也是既兴奋又紧张。我很看重这个项目，从计划、人员配置到团队氛围等，我都处处留意。

　　在我的带领下，我们测试组每天都能发现很多缺陷，开发改不过来了，因为新增的bug数量大于开发每天所能解决的数量，再加上开发团队还要做新功能，这样，就出现了测试压倒开发的"态势"。

　　旁观者说：测试压倒开发，与开发压倒测试一样，不是好的项目状态。二者应当势均力敌，互相制约，互相推动和促进，做出一个好的产品来。

　　整个项目进行期间，测试团队不可谓不努力，但是绩效却不好，也算不上快乐。这其中的原因是什么呢？当时百思不得其解。现在回过头来看，至少有两个方面是可以从中吸取教训的。

　　第一，当时的理念认为测试就是提问题单。现在很多人都知道，这是不对的，测试并不仅仅是发现bug，预防bug也非常重要。

　　第二，没有把开发和测试视作一个完整的团队，而是开发和测试分隔得太"开"。

　　在产品bug非常多的时候，我们没有想到去做缺陷分析，采取一些预防措施，没有问："这类缺陷怎么又出现了？我们能不能走到开发前期，去了解测试做哪些工作，可以帮助预防这类缺陷？甚至测试能不能帮助开发解决一些bug？因为未修复的bug已经堆积很多了"等这样的问题，不认为这些也是自己的工作职责。由于缺乏"预防测试（Preventive Testing）、完整团队（Whole Team）"的思想，测试只是一味地发现缺陷，而大量的缺陷意味着产品质量并不高，测试人员难免会有挫败感。

　　旁观者说：在实际的项目中，有的时候其实也能发现流程或者工作方法方面的一些问题，但是往往因为疲于应对工作，下不了决心来做改进。项目结束后的总结过程是很有必要的，让我们更加清晰地看到不足，制定出具体的改进办法。

　　更多的启发

　　如果深入思考，这个案例可以带给我们更多的启发。

　　第一，如果一个产品或项目有大量的bug暴露出来，作为项目管理者要注意了，这意味着项目本身有很大的改进空间，产品的质量不容乐观。

　　处理bug是很费时间的：测试提交一个bug，开发打回，说这不是bug；测试再打过去，证明这就是一个bug；开发修改后，不经过单元测试，就打给测试去验证；如果测试验证没有通过，还要打回给开发，开发重新修复，测试再重新验证……可以想象，成千上万个bug，如果每一个都要走这样的流程，单是解决掉这些bug就要耗费多么大的精力！每一个bug就是对系统的一次change，软件系统本身已经很复杂了，再加上成千上万次change，系统变得更加复杂，潜藏的缺陷有可能更多！

　　旁观者说：对于全新的功能，我在自己的团队有一个提法：剥笋子。软件的功能都是逐步完善的，在初期很容易发现这样、那样不对的地方，这个时候不要开过多的bug，而应该像剥笋一样一层一层来。先提交最主要的几个bug，开发修改了以后，测试人员得到新的build，再基于新的build提交另几个主要的bug。bug分清楚主次，提交的时间分先后，能够提高bug的有效性，也方便开发人员解决问题，提高研发效率。

　　第二，测试流程只起到辅助性的作用。

　　当时公司已经有了非常不错的测试流程，有很多测试工程方法可以使用，有很多测试文档模板可以选用，我认为只要认真遵守流程规范，就一定能做好测试。在某一个时间点，应该采用什么样的模板、出具什么样的测试文档、使用哪些测试工程方法、开展哪些测试活动、做哪些测试总结和缺陷分析等，我都一一照做，花了不少的时间。但是，遗憾的是，我虽然努力了，却没有抓住事情的本质，忘记了我们的第一目标是要得到一个可发布的高质量软件，而不是找到尽可能多的bug。

　　旁观者说：测试团队天生有想发现更多bug的倾向，有的时候绩效考核会起到推波助澜的作用。但是的确，按时发布质量达到标准的软件产品是任何"参战部队"的最重要的目标。

　　实际上，我现在认为，测试流程是一种启发式（Heuristics），遵守了流程，测试不一定就做得好；不遵守流程，测试也不一定就做不好。测试流程起到的更多的是一个辅助性的作用，而不是决定性的作用。所有的启发式都可以帮助我们思考。我们要学会应用（Apply）测试流程，而不是遵守（Follow）测试流程。