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

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

角色 1： 培训人员

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

1. 收集团队反馈，找出业务薄弱点，列出topic
2. 针对不一样的topic分阶段（sprint）的开展培训和分享
3. 保留培训资料以便之后查询（文档、视频等等）

角色 2：测试规划师　　

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

• 平衡测试和开发工做量

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

1. 1. 测试人员针对用户故事建立测试策略（测试用例、环境配置等）
   2. 相关人员评审（包括测试、PO、负责用户故事的开发人员以及另一位将要负责测试的开发人员）
   3. 评审人员对测试策略达成一致
   4. 用户故事开发人员编写代码，完成之后按照测试策略执行集成测试
   5. 代码CheckIn以后，负责测试的开发人员按照测试策略执行最终测试
   6. 若有必要测试人员在进行简单的功能验证（探索性测试）

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

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

• 尽量多的开展结对测试

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

1. 尽量从多视角来测试功能
2. 培训指导（主要是针对开发人员的一些测试理论和技能）　　　　

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

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

角色 3：产品经理

这里写产品经理，不是说让测试人员去作产品经理，而是说从一个测试人员或者客户的角度来分析用户痛点，而且提出相应的用户故事。这一点测试人员仍是有优点的，毕竟每一个测试人员都是产品的资深用户。

角色 4：工具开发人员

为了提升测试效率，工具开发是很重要的一项。工具不必定是一个庞大的系统，它能够是一个SQL脚本、批处理文件或者是功能简单的执行文件，只要能提升测试效率的均可以尝试去作。

角色 5：自动化工程师

　　自动化测试在测试过程当中是重要的一环，不只能够节省人力，时间并且能够极大的提升测试效率。这里主要指的是端到端的自动化测试，由于单元测试和集成测试的自动化脚本由相应的开发人员负责编写。这时通常须要作的工做是：

1. 针对项目评估相应的测试框架和工具，找出适合的
2. 和开发讨论搭建测试框架
3. 在迭代中，为相应的用户故事用例添加相应的脚本
4. 按期执行

角色 6：全栈工程师

　　这个就很少说了，由于距离远着呢……

 

小结：

其实各个角色之间是没有冲突的，并且是能够根据敏捷团队所处的阶段有所侧重点的。固然目的只有一个，提升效率，保持竞争力。

 

keep growing……