● 故事分析阶段：需求澄清，业务场景和验收测试的确认

　　● 故事计划阶段：拆分测试任务，在每个故事开发估算基础上考虑测试的时间和估算

　　● 故事开发阶段：和开发人员结对实现自动化测试，和团队沟通发现的问题和缺陷

　　● 故事验收阶段：开发人员开发完故事后，QA和业务分析人员要在开发机器上进行验收，以提供快速的反馈；同时还要对测试覆盖率（单元测试、组件集成测试、功能测试）进行确认和提出反馈

　　● 故事测试／探索性测试阶段：执行自动化验收测试，执行探索性测试，强调会阻碍故事发布的因素，和团队测试覆盖率进行沟通，为发现的缺陷添加自动化测试

　　● 系统测试和客户演示阶段：执行端到端的系统测试，执行业务或集成的用户测试场景，和团队及客户功能特性的质量和稳定性进行沟通，参与给客户演示功能和特性

　　正如前面提到的，在每个阶段，QA除了要独立进行测试，通常还需要跟不同的角色结对，包括业务分析人员、开发人员、以及客户。

　　● QA与业务分析人员结对：通常在业务分析师分析用户故事的时候，QA要与业务分析人员结对编写验收标准。通过与业务分析人员结对，QA能够更好的理解领域知识，从而有利于定义合适的测试用例；QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

　　● QA与开发人员结对：QA和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。作为一个团队，好通过平衡不同的技能集来获得共同的目标。这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候，QA与开发人员结对是比较理想的方式。这样结对实现的自动化测试质量相对较高，有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。另一方面，QA通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与QA结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。

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

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