自动化测试

　　测试自动化被许多人看做是敏捷的基石之一，众多的敏捷实践依赖于自动化的程度，例如持续集成。而能够实现增量式开发也需要能够快速、全面地进行回归测试，确认已存在的功能特性没有受到新特性开发的影响。在大张旗鼓地进行敏捷转变之前，我们的产品线就已经开始尝试过测试自动化。一个专门的测试自动化小组在半年多时间内，操作芬兰专家开发的自动化测试工具，将那些执行频率很高的回归测试用例集实现自动化执行。基于由此项目得来的成功经验，测试自动化的概念被广为传播，而且这个实践也开始作为一个基本要求附加给测试团队，自动化测试用例占所有测试用例的比例作为一个指标被上层主管密切关注。

　　开始进行敏捷转变时，围绕着测试自动化有很多的争论，主要的焦点在于是否要追求100%的测试自动化。反对方和支持方都各有理由，难分高下，不同理念都有追随者在实践。支持者认为自动化测试可以节省执行时间，而且可以在夜间及周末进行测试执行。反对者认为实现自动化用例耗用了测试人员的绝大部分时间，来自于基层的部分意见反映他们都没有时间去真正的测试系统，而且还有一些用例非常难实现自动化，或者说成本非常高。而最新的一个情况是，在一个新的版本发布计划中，测试自动化的开销总计以万小时计算，那么是否有必要一定要实现100%测试自动化?

　　我个人认为，其中很重要的一点就是测试自动化以及其比例被作为硬性指标施压给团队，导致团队无暇顾及测试自动化的质量高低。而测试自动化的质量恰恰会影响到：执行时间的长短、维护自动化脚本的开销、实现测试目的的准确性等。另一个原因就是，了解、专长于测试自动化，具备大范围应用测试自动化经验的专家太少，还常常疲于应付实现具体的测试自动化用例，无暇去传授、辅导及培养其他同事的测试自动化技能。

　　流程

　　敏捷的转型过程中，如果认为流程可以被抛弃，可以按照自己的想法去做开发测试，这样的观念将是很大的一个误区。

　　流程之所以为流程是因为它所承载的是一个组织长时间积累的经验与教训，它被实践所证明有效的方式，怎样使做某件事情的效果与效率达到最优，并在多年的实践中被不断的补充。

　　比如同行评审，我们的误区在于认为人们会自动自发的组织好同行评审，可以使用开发组所自己的方式。老的同行评审的传统并没有很好的沿袭，特别在组织大规模扩招的时候。导致的结果是我们的需求，设计代码的问题比以往任何时候都要多。

　　比如测试，组织大规模的调整，但是相对应的测试在新组织里的怎样的计划，新开发组里测试以怎样的方式进行，怎样是最有效率的进行测试，开发组的测试和外部测试之间的区别和协调，测试在端到端的整个开发过程中的布局与充分性。我们的误区是对这些问题在相当长的时间以后才逐渐意识到这方面的缺乏，然后逐渐提出改进。