Scrum是软件开发的敏捷⽅法。它以2到4周为⼀个迭代开发出有价值的商业功能。Scrum团队有两个明显特征：他们是多⾯⼿(例如：他们具备完成⼯作所必须的所有技能);他们是⾃管理的(例如：团队不断探索如何把⼯作做的最好的⽅法)。通过过去两年在Scrum团队中近2年的QA⾓⾊的不断实践，我认识到Scrum中的QA不仅仅是编写测试⽤例和汇报缺陷那么简单。
对⽐传统瀑布模型的项⽬中的同步活动，Scrum期望开发活动根据实际需要的顺序来执⾏，例如异步。这点有悖传统，让许多客户、开发和业务关系⼈等新⼿产⽣疑惑 “如何在代码还没有完成之前进⾏有效的测试?” 本⽂重点解释了QA如何执⾏敏捷测试以及Scrum团队中QA⾓⾊的重要性。我将通过本⽂分享在我对Scrum团队中QA⾓⾊及职责的认识。
不仅是编写测试⽤例传统瀑布模型的项⽬中，QA介⼊的时机往往是在代码全部完成后的项⽬收尾阶段。这些项⽬中，QA拿到⼀份需求⽂档和已经完成的代码，然后开始编写和执⾏测试⽤例以检查应⽤程序是否符合需求⽂档。然⽽，Scrum中的QA⾓⾊不再仅仅是执⾏测试⽤例和汇报缺陷。
在Scrum团队中，QA分析师和其他团队成员⼀起参与或担当⼤量职责。他们从项⽬⼀开始就介⼊，并且与业务分析者和开发者密切联系。在Scrum中，QA不是⼀个单独的测试应⽤程序的团队。取⽽代之的是，Scrum团队是⼀个业务分析师、开发者、QA⼀起协同⼯作的综合团队。除了编写⽤例，QA还帮助产品负责⼈(PO)编写接受⽤例，相当于承担产品负责⼈代理的⾓⾊。当产品负责⼈没有时间时，QA作为代理保持团队持续前进。QA和产品负责⼈通过提出问题和质疑假设进⾏互动交流，最终澄清业务需求。
参加评估
⽤户故事(Story)QA分析师⼀般很擅长根据⽤户需求创建测试⽤例场景。在识别和捕捉复杂和否定的⽤例上也很卓越。事实上，在这点上，QA往往⽐开发做的好，因为开发往往关注⽤户故事的好的⽅⾯。在版本和周期计划会议中评估⽤户故事时邀请QA参与能让团队不再仅仅思考好的⽅⾯，有利于产⽣⼀个综合好坏情况的客观真实的评估。评估是⼀个很难的事情，让所有⼈都参与评估是很好的实践。
有利于保持视⾓和⽬标明确
当团队执⾏测试和其他稳定产品的活动时，QA需要掌控计划、组织或让整个团队投⼊到测试⼯作中，并且像Scrum Master(SM)那样保持成员处于积极状态。很少有开发者喜欢做测试任务。QA需要和Scrum Master⼀起让测试对整个测试团队可见且⽬标明确。从⽽保持开发者或其他成员的积极性。有时⼀些测试场景的构建需要开发或其他团队成员的帮助，这样容易创新。⼒争让测试活动有趣，例如⽤刺激的测试场景、出⼈意料的测试数据和带有娱乐意味的竞争。总之，做任何事情，只要有助于团队乐于加⼊测试⼯作即可。
与客户和开发者紧密合作
QA的主要职责之⼀是将他们的测试结果反馈给产品负责⼈或收集他们的反馈。QA和产品负责⼈紧密合作，帮助他们制定详细的⽤户故事验收标准。随着团队在每个迭代中的深⼊了解，QA也可以帮助产品负责⼈修改或增强⽤户故事以更好地反映真实的需求。
偶尔，QA分析师还充当产品负责⼈代理。这种情况下，QA和开发者将坐在⼀起，作为⼀个团队⼀起⼯作以提⾼产品质量。QA可以和开发者结对来写单元测试，讨论验收标准。合作的⼯作越多，需求也越清楚。⼀起⼯作带来的清晰需求将减少编码过程中经常遇到的各种问题或疑惑，从⽽给有效提⾼开发效率、节约开发和QA的时间。
根据团队每个⼈的需求和实际情况，整个团队将成为⼀体，都会协助测试。这样的实践平衡了团队和⼯作完成必须的共同职责，早期测试反馈和持续增长的质量下，它将使项⽬进展更快。提供快速反馈
传统瀑布模型团队不断重复的“构建-测试-修复”周期徒增了⼤量额外⼯作量，浪费了⼤量时间。在Scrum中，QA和开发者在整个项⽬中⼀起⼯作，让活动变得更简单。在开发过程中，开发者能直接咨询QA验收标准或从⽤户视⾓任何功能上的期待⾏为。这让测试和缺陷修复更简单。⾃动化回归测试⾃动化测试常被誉为测试者最好的朋友，因为它可重复执⾏且执⾏⼀致，能得到更好的软件功能的测试覆盖率。在2到4周⼀个迭代的Scrum项⽬中这点尤为正确。因为QA⼤体都没有太多时间去测试应⽤程序。在2周的迭代中，QA必须完成迭代中所有新功能的功能点测试的同时还要完成对先前实现功能的测试。正因如此，这种职责提⾼了每个迭代中使⽤可⽤的⾃动化实践以减少QA压⼒的重要性。
当团队执⾏持续集成时，⾃动化测试在快速反馈上⼤有⽤途。每发布⼀个软件新版本，可以执⾏⾃动化测试并快速提供反馈以反映是否新⽼功能都正常⼯作。⽽没有⾃动化测试，就必须⼿⼯执⾏所有的测试，不仅单调，⽽且容易犯错。⾃动化测试能更早的发现缺陷，让QA有更多时间去探索新功能的⼀些特殊⽤例。通过⾃动化测试，QA可以更快更有效地完成测试⼯作。参与发布准备演⽰
在每个迭代结束时，团队需要召开⼀个迭代审阅会议来向项⽬责任⼈和其他有兴趣的关系⼈展⽰这个迭代完成的⽤户故事。迭代审阅会议是团队中的“良药”，可以有效激发他们去尽可能完成更多⽤户故事。
在2到4周的⼩迭代中，为了让⽤户故事按时完成，团队中的每个⼈都必须沉浸在⾃⼰的⼯作。开发者关注实现⽤户故事和修复缺陷，QA关注⽤例编写、澄清产品责任⼈的问题、⾃动化之前迭代的测试。较短的迭代周期意味着开发没有多少时间去获知⽤户故事要求的全部功能。这样，开发⼀般要询问QA以更好的理解⽤户故事。因为QA知道完整的功能及每个需求和验收标准。在迭代审阅会议上，让QA演⽰项⽬和解答业务上的问题是很好的实践。这也让开发者更专注于处理技术层⾯的问题。
分析⽤户需求
QA是Scrum团队中产品负责⼈代理。他们擅长从⽤户视⾓理解业务需求。因为他们经常被问到⽤户如何使⽤项⽬。QA根据他们的测试经验给产品负责⼈提供反馈(+本站微信networkworldweixin)，帮助他们更好的从⽤户视⾓理解项⽬。完善“完成定义”
对于敏捷团队，清晰的完成定义(DOD)是很重要的。“完成定义”是团队定义完成标准的简单列表，是在⽤户故事认定为完成必须要完成的事情。完成定义⼀般包括完成代码、执⾏功能和回归测试、获得产品负责⼈的认可。
⼀个简单的完成定义可能包括如下项⽬：
代码完成单元测试完成功能和UI测试完成产品负责⼈认可定义“完成定义” 不是QA⼀个⼈的责任，QA的责任往往在于监管团队完成定义和每个完成的⽤户故事必须满⾜“完成定义”的基线要求。⼀个⾼效的敏捷团队在启动每个⽤户故事前都要审阅“完成定义”从⽽使团队每个⼈都了解⽬标。“完成定义”不是⼀层不变的，可能会根据Scrum的需要不断演变。“完成定义”既可以是迭代级的也可以是发布级的。
⽤测试策略规范测试
由于Scrum团队中没有测试领导甚⾄测试专家。构建测试计划或执⾏测试策略就存在问题。Scrum认为需要准备⾜够的⽂档去⽀持团队随时提出的需求。正因为此，需要准备⾜够的⾼层次测试策略的⽂档和计划来指导团队。因为没有QA领导在团队中，QA⼀般⾃⼰来制定测试策略。
测试者和分析者⾓⾊融合
测试者和分析者⾓⾊融合在敏捷团队中很常见，业务分析师的⾓⾊⼀般是负责创建和维护迭代和产品的Backlog、从业务⾓度分析⽤户故事、根据产品负责⼈要求划分⽤户故事优先级。⽽QA⾓⾊⼀般负责为每个故事定义或完善验收标准，确保之前完成的功能没有⽼的问题。QA测试每个⽤户故事，从终端⽤户视⾓验证定义的验收标准是否已经达到，他们也根据业务来分析⽤户故事。所以QA和业务分析师的⾓⾊责任、必备技能、总体⽬标有很多重合地⽅。⼀般，在项⽬开始之时，敏捷团队从产品负责⼈那⾥拿到⽤户故事和提前定义的项⽬范围。在敏捷模式下，⿎励团队成员提出改善终端⽤户体验的新功能或改变已有功能，也⿎励团队⼀旦发现技术依赖或发现换⼀种实现将更有效⽽改变备份⽇志中⽤户故事优先级和顺序。⽆论是定义需求、分析⽤户故事、定义和澄清验收标准、编写接受性验证⽤例或和⽤户紧密合作，对于⼩的团队，测试者和分析者的⾓⾊融为⼀体有很多优点，但也存在⼀些缺点，最⼤的顾虑是没有测试者或分析者能够投⼊过多精⼒来完全尽责。
结论
除了编写⽤例和汇报缺陷，QA在Scrum团队中承担更多的职责。他们是团队的重要组成部分，并且从项⽬⼀开始就参与其中。
联系我们
Contact us
战略解码