分析用户需求QA是Scrum团队中产品负责人代理。他们擅长从用户视角理解业务需求。因为他们经常被问到用户如何使用项目。QA根据他们的测试经验给产品负责人提供反馈，帮助他们更好的从用户视角理解项目。 完善“完成定义”对于敏捷团队，清晰的完成定义(DOD)是很重要的。“完成定义”是团队定义完成标准的简单列表，是在用户故事认定为完成必须要完成的事情。完成定义一般包括完成代码、执行功能和回归测试、获得产品负责人的认可。一个简单的完成定义可能包括如下项目：
定义“完成定义” 不是QA一个人的责任，QA的责任往往在于监管团队完成定义和每个完成的用户故事必须满足“完成定义”的基线要求。一个高效的敏捷团队在启动每个用户故事前都要审阅“完成定义”从而使团队每个人都了解目标。“完成定义”不是一层不变的，可能会根据Scrum的需要不断演变。“完成定义”既可以是迭代级的也可以是发布级的。 用测试策略规范测试由于Scrum团队中没有测试领导甚至测试专家。构建测试计划或执行测试策略就存在问题。Scrum认为需要准备足够的文档去支持团队随时提出的需求。正因为此，需要准备足够的高层次测试策略的文档和计划来指导团队。因为没有QA领导在团队中，QA一般自己来制定测试策略。 测试者和分析者角色融合测试者和分析者角色融合在敏捷团队中很常见，业务分析师的角色一般是负责创建和维护迭代和产品的Backlog、从业务角度分析用户故事、根据产品负责人要求划分用户故事优先级。而QA角色一般负责为每个故事定义或完善验收标准，确保之前完成的功能没有老的问题。QA测试每个用户故事，从终端用户视角验证定义的验收标准是否已经达到，他们也根据业务来分析用户故事。所以QA和业务分析师的角色责任、必备技能、总体目标有很多重合地方。 一般，在项目开始之时，敏捷团队从产品负责人那里拿到用户故事和提前定义的项目范围。在敏捷模式下，鼓励团队成员提出改善终端用户体验的新功能或改变已有功能，也鼓励团队一旦发现技术依赖或发现换一种实现将更有效而改变备份日志中用户故事优先级和顺序。无论是定义需求、分析用户故事、定义和澄清验收标准、编写接受性验证用例或和用户紧密合作，对于小的团队，测试者和分析者的角色融为一体有很多优点，但也存在一些缺点，最大的顾虑是没有测试者或分析者能够投入过多精力来完全尽责。 结论除了编写用例和汇报缺陷，QA在Scrum团队中承担更多的职责。他们是团队的重要组成部分，并且从项目一开始就参与其中。 过去两年在Scrum团队当QA分析师让我有了一个非常棒的体验，同时也获得了很多学习机会。我担当了很多不同的角色和职责，包括QA分析师、产品责任人代理、帮助开发写单元测试、确保团队的质量意识和跟踪问题和软件缺陷。总之，这些体验让我获得了很多 不错的技能，同时让我学习了如何做好不同的角色。更重要的是它告诉我如何去问问题而不再是仅仅遵循文档，也教会了我去做任何有助团队成功的事情。 关于作者
|
Priyanka Hasija：是Xebia IT Architects的一名测试咨询师，从事IT业已两年。期间，她对敏捷原则有了深刻理解并有机会在一些敏捷项目中成功应用。在Xebia工作期间，Priyanka不仅积累了手工测试经验，也积累了采用Jmeter、Selenium等工具进行自动化测试的经验。她是一名热情的博主，曾写下不少测试文章，主题涉及Jmeter、Selenium、SoapUI和探索性测试。另外，她在2011的Agile Tour-Hyderabad会议中参与主持一个主题。
