敏捷下的质量保证实践

对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。

如何做呢？单元测试就开发人员处理了；代码审查，测试人员可以参与和监督，其实就是要保证：将开发任务与提交到Git的代码进行关联。

这样一来，当测试人员检查开发任务的时候，就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。

Scrum中测试人员价值应当体现在：

预防缺陷的手段，提高洞察力，增强业务知识。

缺陷在需求、开发前期就已经存在了，关键是用什么手段去挖掘出来预防。在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与git双向关联来做检查依据。

目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；

并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。当然，这是远景。

持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

敏捷中的QA日常活动

从迭代到发布，敏捷测试的生命周期各个阶段QA的活动主要有：测试分析，测试自动化策略分析、框架构建等，故事测试，迭代计划会议和客户演示，测试自动化的维护和执行等。如下图示：

QA通常不是仅仅工作在某个迭代，而是并行的同时工作在多个迭代：要对当前迭代的故事进行验收测试、探索性测试，和开发人员结对实现测试自动化；还要和业务人员结对分析下一个迭代的故事，编写验收标准和测试用例。

在单个迭代内部，伴随着故事生命周期，QA的活动有哪些呢？用户故事生命周期包括以下几个阶段：故事分析、故事计划、故事开发、故事验收、故事测试／探索性测试、系统测试和客户演示。

QA参与故事的整个生命周期，在每个阶段都会发挥作用。

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

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

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

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

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

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

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

QA与业务分析人员结对：通常在业务分析师分析用户故事的时候，QA要与业务分析人员结对编写验收标准。

通过与业务分析人员结对，QA能够更好的理解领域知识，从而有利于定义合适的测试用例；QA从测试角度添加的验收测试用例可以帮助整个团队对产品功能性有更好的理解。

QA与开发人员结对：QA和开发人员分别能给团队带来不同的技能集，认识到这一点很重要。作为一个团队，最好通过平衡不同的技能集来获得共同的目标。

这对于传统的瀑布式团队来说是一个很重要的心态改变。通常在实现测试自动化的时候，QA与开发人员结对是比较理想的方式。

这样结对实现的自动化测试质量相对较高，有测试意识较强的QA参与能够保证自动化测试测得是真正需要测试的部分，而开发人员的编码能力有利于写出简洁可维护的自动化测试代码。

另一方面，QA通过与开发人员结对，编码能力也会相应有所提高，而开发人员通过与QA结对，测试意识也会增强，更有利于编写质量较高的产品代码，更有利于形成全功能团队。

QA与客户结对：客户是业务领域专家，通过与客户结对，QA能够更好的从终端用户的角度理解系统，从而定义或者增加更多的端到端的测试用例；

一旦QA理解了领域知识和终端用户的观点，其业务价值分析能力会有所提高，在团队需要的时候可以承担业务分析角色；

在用户验收测试（UAT）阶段，QA通过与客户结对，帮助客户熟悉使用系统，在必要时可以帮助客户解决一些系统问题。

敏捷QA的这些日常活动，的确反映出敏捷QA的日常工作内容和方式都跟传统开发模式下的测试人员有很多不同。

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

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

敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证；

不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。

比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

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

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

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

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

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

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

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

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

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

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

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

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

持续提供并获取反馈