敏捷软件开发中的QA(2)

　　QA与客户结对：客户是业务领域专家，通过与客户结对，QA能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例;一旦QA理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段，QA通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。

　　敏捷QA的这些日常活动，的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同，以及敏捷测试对QA的要求有哪些。

　　敏捷QA与传统测试人员有何不同

　　我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面，来看看敏捷QA与传统测试人员有哪些不同：

　　从上表的对比可以看到，敏捷QA是特殊的，主要体现在：

　　敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

　　发现风险，并将风险与团队及客户沟通。QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的，因此也更容易看到系统存在的风险。

　　及时向团队提供关于产品质量的反馈，便于调整。在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。

　　在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。

　　QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。比如：在故事验收阶段对测试覆盖率的确认。

　　这些特殊性对敏捷QA也提出了更高的要求，需要做到：

　　具有丰富的产品知识和对用户业务目标的准确了解

　　对不同系统和数据库所用到的技术知识的了解

　　和不同角色以及客户进行有效沟通

　　主动验证质量目标并及时说出自己的想法

　　编写测试计划，列出需要执行的活动并进行估算

　　自动化测试的能力和对测试工具的基本了解

　　在团队内部进行知识分享，协助整个团队参与到测试活动中来

　　持续提供并获取反馈

原文转自：http://www.uml.org.cn/Test/201302262.asp