Scrum是软件开发的敏捷方法。它以2到4周为一个迭代开发出有价值的商业功能。Scrum团队有两个明显特征：他们是多面手（例如：他们具备完成工作所必须的所有技能）；他们是自管理的（例如：团队不断探索如何把工作做的最好的方法）。通过过去两年在Scrum团队中近2年的QA角色的不断实践，我认识到Scrum中的QA不仅仅是编写测试用例和汇报缺陷那么简单。
对比传统瀑布模型的项目中的同步活动，Scrum期望开发活动根据实际需要的顺序来执行，例如异步。这点有悖传统，让许多客户、开发和业务关系人等新手产生疑惑 “如何在代码还没有完成之前进行有效的测试？” 本文重点解释了QA如何执行敏捷测试以及Scrum团队中QA角色的重要性。我将通过本文分享在我对Scrum团队中QA角色及职责的认识。
不仅是编写测试用例
传统瀑布模型的项目中，QA介入的时机往往是在代码全部完成后的项目收尾阶段。这些项目中，QA拿到一份需求文档和已经完成的代码，然后开始编写和执行测试用例以检查应用程序是否符合需求文档。然而，Scrum中的QA角色不再仅仅是执行测试用例和汇报缺陷。
参加评估用户故事（Story）在Scrum团队中，QA分析师和其他团队成员一起参与或担当大量职责。他们从项目一开始就介入，并且与业务分析者和开发者密切联系。在Scrum中，QA不是一个单独的测试应用程序的团队。取而代之的是，Scrum团队是一个业务分析师、开发者、QA一起协同工作的综合团队。除了编写用例，QA还帮助产品负责人（PO）编写接受用例，相当于承担产品负责人代理的角色。当产品负责人没有时间时，QA作为代理保持团队持续前进。QA和产品负责人通过提出问题和质疑假设进行互动交流，最终澄清业务需求。
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根据他们的测试经验给产品负责人提供反馈，帮助他们更好的从用户视角理解项目。
完善“完成定义”
对于敏捷团队，清晰的完成定义(DOD)是很重要的。“完成定义”是团队定义完成标准的简单列表，是在用户故事认定为完成必须要完成的事情。完成定义一般包括完成代码、执行功能和回归测试、获得产品负责人的认可。一个简单的完成定义可能包括如下项目：
代码完成
单元测试完成
功能和UI测试完成
产品负责人认可
