对于开发模式，现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型，这种转型相对传统的测试人员来说，不论是在角色定位还是在技能栈方面都提出了更大的挑战，那么测试人员应该如何应对呢？下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向，供大家参考：
角色 1： 培训人员
在转型初期，测试人员应该针对开发人员的薄弱环节（即业务技能）进行培训和指导。由于工作任务的差别，开发人员对负责的模块业务和具体实现细节非常了解，但是对周边模块或者业务并不是非常清楚，主要体现在配置和使用方面。而这部分恰恰是测试人员有经验的地方，这个时候需要测试人员尽可能多的开展一些培训和分享工作，使团队尽可能快速的弥补不足，在之后用户故事的开发过程中对业务有一个更好的把控。培训开展的几个步骤如下：
- 收集团队反馈，找出业务薄弱点，列出topic
- 针对不同的topic分阶段（sprint）的开展培训和分享
- 保留培训资料以便以后查询（文档、视频等等）
角色 2：测试规划师
对于测试规划师，我认为主要的职能是规划如何高效（时间、资源、质量）的推进用户故事测试的开展。要做到这一点真的很不容易，需要从两方面来考虑：
- 平衡测试和开发工作量
在敏捷团队中测试人员和开发人员的比例悬殊的情况下（主要是开发人员多，至少现在我还没见过测试比开发多的团队^_^），对于工作量来说，测试人员不可能匹配开发的速度，这时就需要开发人员给予一定的帮助，开展的几个步骤：
-
- 测试人员针对用户故事创建测试策略（测试用例、环境配置等）
- 相关人员评审（包括测试、PO、负责用户故事的开发人员以及另外一位将要负责测试的开发人员）
- 评审人员对测试策略达成一致
- 用户故事开发人员编写代码，完成以后按照测试策略执行集成测试
- 代码CheckIn之后，负责测试的开发人员按照测试策略执行最终测试
- 如有必要测试人员在进行简单的功能验证（探索性测试）
步骤比较简单，但是操作起来并不容易，首先需要对测试人员进行简单的测试理论培训，包括一些测试方法，测试思想等（不可能单靠培训有很大的提升，需要在测试中慢慢积累），然后就是开发人员是不是愿意做测试工作，我想这也是转型中遇到的一个很大的问题，不过还好，我们团队的开发都很nice，有些同学还会主动要求做一些测试工作，这是出乎我意料的。这里我还是要说一下，开发人员做一些测试其实是有很多好处的，主要体现在代码质量意识、业务理解能力和个人技能栈的提升等。当然，还是有些小伙伴们不愿意做测试的任务，那就没办法了，反正会做测试的开发普遍变美变帅了~
那么问题来了，测试人员是不是一直要负责为用户故事创建测试策略呢？当然不是，当开发人员对测试有进一步的了解之后，可以尝试着让开发创建测试策略，测试人员负责评审，等到测试人员提不出来太多的改动的时候，测试人员就可以失业了。
- 尽可能多的开展结对测试
结对测试就是由两个团队成员共同测试同一个功能。这样做的目的有两个：
- 尽可能从多视角来测试功能
- 培训指导（主要是针对开发人员的一些测试理论和技能）
- 适当的时机开展探索性测试
这个阶段是相对进阶一些的测试方式，主要是在开发人员具备了一定的测试方法和思想之后开展的。执行探索性测试的时机是在每完成一个重要功能之后，组织多名开发和测试人员针对一条功能主线进行探索，寻求发现尽可能多的潜在问题。
角色 3：产品经理
这里写产品经理，不是说让测试人员去做产品经理，而是说从一个测试人员或者客户的角度来分析用户痛点，并且提出相应的用户故事。这一点测试人员还是有优势的，毕竟每个测试人员都是产品的资深用户。
角色 4：工具开发人员
为了提高测试效率，工具开发是很重要的一项。工具不一定是一个庞大的系统，它可以是一个SQL脚本、批处理文件或者是功能简单的执行文件，只要能提高测试效率的都可以尝试去做。
角色 5：自动化工程师
自动化测试在测试过程中是重要的一环，不仅可以节省人力，时间而且可以极大的提高测试效率。这里主要指的是端到端的自动化测试，因为单元测试和集成测试的自动化脚本由相应的开发人员负责编写。这时一般需要做的工作是：
- 针对项目评估相应的测试框架和工具，找出适合的
- 和开发讨论搭建测试框架
- 在迭代中，为相应的用户故事用例添加相应的脚本
- 定期执行
角色 6：全栈工程师
这个就不多说了，因为距离远着呢……
最后分享一句罗胖子听王兴说的美国创业圈的一句英语：keep growing, fuck everything else. 就酱~~