聊聊敏捷开发模式下测试人员的定位

treeou

前言：

  做测试有些年头了，一直没在论坛上发过言，今天开个头和大家聊几句。

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

正文：

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

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

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

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

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

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

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

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

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

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

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

  以上，通过过往的工作经验整理了一些想法，希望对广大测试人员有所借鉴和帮助。

梦想家

多谢分享

Miss_love

自动化也只能完成一部分工作，大部分工作还是得人工来完成，高度的迭代如何保证测试质量，值得思考

Lyangmeng

传统瀑布型的嵌入式开发过程的敏捷测试该如何介入呢？

treeou

其实没有“敏捷测试”的说法，敏捷只是一种方法，通过频繁而有效的沟通、交流，规避过往以电子化为主的协作方式（看起来有点反CMMI）的弊端，目的就是让团队的每一个成员更加了解本阶段的工作目标和软件需求，加深彼此相知和融合。所以，所谓“敏捷测试”，就是采用敏捷方法的测试过程，全员行动（测试），并辅以自动化测试工具的支撑，让测试活动更有效、更快速。