源起：测试部引入持续集成实践，通过每日自动化测试发现系统的一些问题，开发人员也比较认同，一段时间内大家都比较满意。后来测试人员发现跟踪每天新发现问题的解决进度比较困难，基本上靠手工记录，需要定期询问开发人员的解决进展，基本上是个苦力活。

　　测试人员想到使用现有的bug管理系统来管理这些持续集成发现的问题，于是某天向一位有多年开发经验的朋友咨询意见，结果遭到这位朋友的强烈反对。两人对持续集成这个活动本身也进行了一番激烈的争论。争论的焦点如下：

　　1、在非正式版本上集成测试得到的结果是否可信？

　　2、频繁集成是加重开发人员的负担还是减轻开发人员负担？

　　3、尽早发现问题是否真能带来益处？

　　第一点，在非正式版本上集成测试得到的结果是否可信？

　　开发：每日build版本，因为功能未开发完、代码未完全提交等原因可能造成集成、测试的失败，不一定真是代码本身的问题，所以测试结果不可信。

　　测试：每日build的失败确实有功能未开发完、代码未完全提交的原因。所以对发现的问题要区别对待，如果确实是功能正在开发过程中，应该不算作问题。并且如果软件本身功能开发周期长的话确实不大适合做功能性的测试。但是依然可以需要进行编译、链接、单元测试，尽早发现这方面的问题，提供项目质量方面的反馈。

　　开发：测试代码本身也可能有问题，测试失败后分析是测试代码本身问题还是软件问题也需要时间，增加了成本。

　　测试：一般情况下测试结果都需要经过测试人员的分析，确定非测试代码本身的问题后才会找开发人员参与问题分析。bug的初步分析确实需要时间，这也是每日集成的代价之一吧。

　　第二点，频繁集成是加重开发人员的负担还是减轻开发人员负担？

　　开发：开发人员每天都安排了很多的开发任务，如果还要解决每日集成bug，会增加负担

　　测试：表面上看解决每日集成bug是增加了开发人员的负担，其实这些bug无论是每日解决还是最终某一阶段集中解决，bug数量都没有变化，一样要解决。并且尽早解决bug的代价比后期集中解决的代价小的多。

　　开发：每个人解决bug的习惯不同，有些人就是喜欢集中解决bug，这样效率也高

　　测试：这确实有个人习惯的问题，对个人来说，感觉上效率是高了，但是从统计学角度来讲，引入新bug的机会也变大了，并且集中解决完bug后测试人员还需要回归测试，如果测试到引入了新bug，还需要修改新bug，然后再回归...正是集中解决bug的方式给开发人员带来了更大负担而不是每日解决的方式。并且开发人员在压力下集中解决bug更容易因为心理原因引入更多bug。

　　第三点，尽早发现问题是否真能带来益处？

　　开发：都认为尽早发现问题很有益，但是从个人经验方面看，没发现有多大的价值。

　　测试：敏捷软件开发方式强调尽早获得反馈，尽早发现bug也是软件质量反馈的一方面。并且从bug寿命周期来说，越晚解决成本越高，这一点应该不是空穴来风。

　　最终两人在这几点上也没有多少的共识。