测试人员在敏捷团队中扮演的角色

 

　　对于开发模式，现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型，这种转型相对传统的测试人员来说，不论是在角色定位还是在技能栈方面都提出了更大的挑战，那么测试人员应该如何应对呢？下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向，供大家参考：

 

　　角色 1： 培训人员

 

　　在转型初期，测试人员应该针对开发人员的薄弱环节（即业务技能）进行培训和指导。由于工作任务的差别，开发人员对负责的模块业务和具体实现细节非常了解，但是对周边模块或者业务并不是非常清楚，主要体现在配置和使用方面。而这部分恰恰是测试人员有经验的地方，这个时候需要测试人员尽可能多的开展一些培训和分享工作，使团队尽可能快速的弥补不足，在之后用户故事的开发过程中对业务有一个更好的把控。培训开展的几个步骤如下：

 

　　收集团队反馈，找出业务薄弱点，列出

 

　　针对不同的topic分阶段（sprint）的开展培训和分享

 

　　保留培训资料以便以后查询（文档、视频等等）

 

　　角色 2：测试规划师

 

　　对于测试规划师，我认为主要的职能是规划如何高效（时间、资源、质量）的推进用户故事测试的开展。要做到这一点真的很不容易，需要从两方面来考虑：

 

　　平衡测试和开发工作量

 

　　在敏捷团队中测试人员和开发人员的比例悬殊的情况下（主要是开发人员多，至少现在我还没见过测试比开发多的团队^_^），对于工作量来说，测试人员不可能匹配开发的速度，这时就需要开发人员给予一定的帮助，开展的几个步骤：

 

　　测试人员针对用户故事创建测试策略（测试用例、环境配置等）

 

　　相关人员评审（包括测试、PO、负责用户故事的开发人员以及另外一位将要负责测试的开发人员）

 

　　评审人员对测试策略达成一致

 

　　用户故事开发人员编写代码，完成以后按照测试策略执行集成测试

 

　　代码CheckIn之后，负责测试的开发人员按照测试策略执行最终测试

 

　　如有必要测试人员在进行简单的功能验证（探索性测试）

 

　　步骤比较简单，但是操作起来并不容易，首先需要对测试人员进行简单的测试理论培训，包括一些测试方法，测试思想等（不可能单靠培训有很大的提升，需要在测试中慢慢积累），然后就是开发人员是不是愿意做测试工作，我想这也是转型中遇到的一个很大的问题，不过还好，我们团队的开发都很nice，有些同学还会主动要求做一些测试工作，这是出乎我意料的。这里我还是要说一下，开发人员做一些测试其实是有很多好处的，主要体现在代码质量意识、业务理解能力和个人技能栈的提升等。当然，还是有些小伙伴们不愿意做测试的任务，那就没办法了，反正会做测试的开发普遍变美变帅了

 

　　那么问题来了，测试人员是不是一直要负责为用户故事创建测试策略呢？当然不是，当开发人员对测试有进一步的了解之后，可以尝试着让开发创建测试策略，测试人员负责评审，等到测试人员提不出来太多的改动的时候，测试人员就可以失业了。

 

　　尽可能多的开展结对测试

 

　　结对测试就是由两个团队成员共同测试同一个功能。这样做的目的有两个：

 

　　尽可能从多视角来测试功能

 

　　培训指导（主要是针对开发人员的一些测试理论和技能）

 

　　适当的时机开展探索性测试

 

　　这个阶段是相对进阶一些的测试方式，主要是在开发人员具备了一定的测试方法和思想之后开展的。执行探索性测试的时机是在每完成一个重要功能之后，组织多名开发和测试人员针对一条功能主线进行探索，寻求发现尽可能多的潜在问题。

 

原文转自：http://www.cnblogs.com/AlwinXu/p/6130106.html