敏捷开发中的测试人员

敏捷开发中的测试人员

• 敏捷开发团队介绍
• 测试人员需要具备的素质
• 测试人员的主要职责
• 定义质量 (Define Quality)
• 交流缺陷（Communication）
• 及时反馈 (Feedback):
• 敏捷开发中QA的职责之敏捷中的QA
• 敏捷QA的日常活动
• 敏捷QA与传统测试人员有何不同

本部分将简要介绍敏捷开发中测试人员所需要具备的素质和职责。

敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 2）。每天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制作精良的 Excel 表格），并及时解决每个人所提出的问题。

测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号：测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求：

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

总结而言，有三方面的基本素质要求：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中，各个测试阶段对测试人员的能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写 ( 比如功能测试 )。但是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。

测试人员的主要职责

在敏捷软件开发中，测试人员的职责有三个主要方面：

定义质量 (Define Quality)

这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。

交流缺陷（Communication）

敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。

及时反馈 (Feedback):

敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。
这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。
另外，我们的测试框架提供自助测试 (Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。

敏捷开发中QA的职责之敏捷中的QA

QA，通常指的是质量保证(Quality Assurance)工程师，但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst)，主要基于以下几个方面的原因：

质量保证更偏向于工业说法，称参与软件测试的人员为质量分析师感觉更恰当;

质量保证师更多的还是把测试当作软件质量的最后把关着、看门人，而敏捷中的QA更多的是建议提供者而非看门人，把QA称为质量分析师更能体现敏捷中团队对质量负责的原则;

质量分析师更重视业务价值，关注业务价值的分析。

QA，质量分析师，显然与测试有关。敏捷中的QA，也就是与敏捷测试有关。敏捷测试就是在敏捷开发模式下对软件进行的测试，要求尽早测试、频繁测试，以及时提供反馈。敏捷测试要求团队对软件产品的质量负责，而不是某个带有QA头衔的特殊人员。 敏捷中的QA可以是参与敏捷测试的所有团队人员，而并不一定是特定的专职的测试人员。

这听起来是不是有点特别?跟传统开发模式下的测试人员是不是有些不一样?别急，我们先来看看敏捷中的QA是如何进行日常工作的。

敏捷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需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。

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

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

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

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

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

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

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

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

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

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

• 持续提供并获取反馈

大家熟悉的测试工作(也是传统的瀑布式)，是接到项目后参与需求评审，然后根据需求文档写写用例和准备脚本，等开发提测之后正式开始测试、提bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题，但缺点是：

• 测试过程是在一定时间间隔内发生的，测试人员必须等待产品完全构建才能找到错误和故障。不可否认，花费的时间超过了可以商定的时间；
• 测试同学非常被动：当需求质量、开发质量差的时候，你只能被动接受，结果就是你会进行漫长痛苦的测试过程以及因为质量差导致上线延期；
• Bug的成本在后期是非常高的，需要花费很多精力和时间去修复。甚至严重的情况是产品都不能按时发布，导致很大的损失。
• 很有可能一个线上问题裸奔了几个月，最后是业务方先发现才排查到是Bug导致，由于影响时间过长给公司造成的损失巨大，还被质疑为什么这么明显简单的问题上线之后没人发现。