聊聊敏捷开发模式下测试人员的定位 - 51Testing软件测试论坛

在敏捷开发理论框架下，测试人员与开发人员的界限已不在清晰，这让传统测试人员产生非常大的困惑：测试活动的地位被消弱了吗？测试人员没有用了吗？测试人员必须得掌握编码知识吗？这是我们经常遇到的疑问。本文试着从我们2年多的敏捷开发实践经验来分析一下这个问题，为测试人员解解惑。

部门从2014年开始大力推广敏捷开发模式，我们项目组也不例外，如今，下面这个场景已经司空见惯：进入开发大厅，一眼忘去，四周的黑板、墙面上贴满了纸条，空调开启，随风飘舞。至此后，早晚时间，人头攒动，会议室常满，办公室异常热闹。

引入敏捷模式之后，最大的变化是项目过程明显加快了，每天纸条上的任务像挥不去的梦魇，压得各位兄弟姐妹喘不过气。没办法，自己挖坑自己埋，自己领的任务自己干。项目组人员像拼命三郎一样干活，代码量像吃了激素一样快速增长，一周或二周一个版本，开发、测试；开发、测试...周而复始。可是，过了不久，项目经理就坐不住了，测试、测试、测试呢！为什么这么长时间还没测试完？

其实，开始实施敏捷的时候，大家忽略了一个重要的问题--如何测试，理论上讲，敏捷开发模式要求整个项目组都要敏捷起来，如果有任何一个环节没有敏捷，就像常说的“木桶效应”一样，整个过程就被拖慢了，而在整个环节中，测试活动的敏捷是非常重要的，也是最困难的（以往的测试活动多是手工做的，现在版本释放周期短了，测试工作也自然困难了。）

可是有人要问了，敏捷模式下不是不需要专门的测试人员了吗，因为这事还搞得测试体系人员人心慌慌的，好像是敏捷升起，我将坠落的样子。可是，我们仔细品味下这句话：“敏捷模式下不需要专门的测试人员...”，人家也没说不要测试活动了呀！人家的意思是说开发人员和测试人员的界限划分不明显了，没说不用测试人员啦！于是，心思得解，测试团队表示：先贤已经说过了，测试活动是保证软件质量的最重要、最有效手段，这个是永远不变的真理。

的确，目前看，这名话说得确实没错，在没有出现更加强大的、智能化的开发工具前，测试活动仍然是保证软件质量的最有效手段。只不过，在敏捷盛行的时代，我们要重新理解并完善测试这个活动。说白了，就是与时俱进，如何让测试活动像整个开过程一样敏捷起来。从目前有效的解决办法来看，就是引入自动化测试工具，通过自动化测试手段让测试活动变得更加迅速，并且是全生命周期的引入，从单元测试、集成测试到系统阶段，全面引入。（ps：关于引入自动化测试这个话题比较大，实施起来也很有难度，涉及到在什么时间引入、引入什么工具、与之配合的工作流程是什么等问题，不是一二句可以说清楚的，以后再慢慢聊。）

说到这大家就清楚了，敏捷开发模式不是不需要测试人员了，而是开发活动和测试活动融合得更加深了，可以说是开发人员和测试人员的界限划分不明显了，也可以理解为对测试人员的要求更高了。估计说到这，有的测试人员激动了（还好哥以前码过一阵程序，不用被淘汰。）、有的测试人员被动了（完了，上面刚解完心宽，怎么唠着唠着又要失业了呢！），就会问：你的意思就是说测试人员还得能编几行代码呗，是不是这样？你说？是不是这样？

各位测试界同学先败着急，坐好，喝口水压压惊。大家都是做测试的，再看看上面的文字，仔细核对一遍，那有一句说了测试人员必须要写代码了，肯定没说，上文只是说对测试人员的要求高了，这样才能更好的执行自动化测试工作。

其实，在我看来，敏捷模式下也必须要有专职的测试人员存在，并且，专职测试人员不一定要会写代码（当然，会写更好。）。原因如下：

1、自动化测试覆盖率不高
从目前实施经验来看，一个成熟的组织能够将自动化测试的覆盖率做到50~60%已经十分不易，而对于新功能（系统）的自动化测试，能做到30%的覆盖率就已经很成功了。所以，还要有大量的工作需要手工方式来做。

2、自动化测试工具更加易用了
思想的进步和技术的发展已经让自动化测试工具变得非常易用，优秀的自动化测试框架已将应用人员的技术要求降到最低，彻底摆脱了传统的“录制->调试”的复杂模式，基本上可做到“积木式”脚本的制作过程（直观的通过界面元素编写脚本的模式，所见即所得，简单易用，老少皆宜。），所以即使你不会写代码，也能做自动化测试。

3、集成后的模块（系统）要统一验证
模块内的自动化测试执行起来相对容易，但是整个产品最终集成后，是否能如期完成业务要求却是未知的，甚至有的时候是多个系统间有业务关系，要相互传递数据。所以，整个开发团队里要有专门的人员，负责把整体集成后的测试工作抓起来。这项工作不是具体的某一功能的测试，而是一种更宏观的、面向整个系统的验证工作。换句话说，就是要验证集成在一起的系统是可以工作的，而这个工作往往是自动化工具不能完成的。