QA与开发人员结对：QA和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。作为一个团队，好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候，QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高，有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面，QA通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与QA结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。
　　QA与客户结对：客户是业务领域专家，通过与客户结对，QA能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例;一旦QA理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色;在用户验收测试(UAT)阶段，QA通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。
　　敏捷QA的这些日常活动，的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。下面为大家来详细介绍一下两者的不同，以及敏捷测试对QA的要求有哪些。
　　敏捷QA与传统测试人员有何不同
　　我们分别从团队构成、测试阶段、工作方式、关注点、业务知识来源以及发布计划制定几个方面，来看看敏捷QA与传统测试人员有哪些不同：
　　  传统测试人员                     敏捷QA
　　单独的测试团队               多角色开发团队的一员
　　在开发流程后期才开始测试      测试贯穿于整个开发流中
　　通常是独立工作                QA和不同角色进行结对
　　被当作后也是的质量保证    关注并强调风险
　　缺乏与业务人员的直接沟通        和业务人员直接沟通
　　没有机会参与发布计划制定        参与发布计划的制定
　　从上表的对比可以看到，敏捷QA是特殊的，主要体现在：
　　敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程后来对系统进行验证;不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
　　发现风险，并将风险与团队及客户沟通。QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边全面的，因此也更容易看到系统存在的风险。
　　及时向团队提供关于产品质量的反馈，便于调整。在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。
　　在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。
　　QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。比如：在故事验收阶段对测试覆盖率的确认。
　　这些特殊性对敏捷QA也提出了更高的要求，需要做到：
　　具有丰富的产品知识和对用户业务目标的准确了解
　　对不同系统和数据库所用到的技术知识的了解
　　和不同角色以及客户进行有效沟通
　　主动验证质量目标并及时说出自己的想法
　　编写测试计划，列出需要执行的活动并进行估算
　　自动化测试的能力和对测试工具的基本了解
　　在团队内部进行知识分享，协助整个团队参与到测试活动中来
　　持续提供并获取反馈