敏捷团队需要专职QA么？｜洞见

敏捷QA对职业发展的担忧

最近和组内的QA聊起以后的职业发展，发现一个有意思的事情，有说想转BA的，有说想转开发的，有说想转型作PM的，还有想以后往咨询方向发展的。很少有说想在团队里面继续作QA的。QA这个角色难道就这么没有吸引力么？为什么都想转型或者自己出去单干呢？和组里几个QA聊了之后，发现主要因素在于对QA职业发展的担忧，觉得敏捷团队对专职QA的需求并不大。

记得我刚工作的时候还是有独立测试团队的，那个时候分工很明确，我就负责windows mobile（现在叫windows phone）上应用的自动化测试，我的这个职位叫做SDET，说通俗点就是自动化测试工程师。我们这个团队大概有10人，测试完毕后将结果汇报给测试经理。由于产品复杂，需要大量的测试工程师以保证产品能顺利发布。随着更多功能的加入，测试团队的人数也在增加，这段时间是QA最有价值感的时候，产品的发布最终都由你来把关，你可以根据兴趣来选择以后做一个性能测试或者安全测试工程师等等，有明确的发展路线。

但现在越来越多的公司选择了敏捷转型，适应变化和快速交付可工作的软件成为了团队的关注点。从开发和用户的角度看，他们会很乐意接受这个变化，客户可以不断看到新功能，开发可以把精力从繁琐的文档和流程上释放出来，发挥想象和创意来提供更好的解决方案。可对于QA来说，敏捷带来了什么好处呢？之前定期有一个可测的稳定版本，详细的需求文档就是我们参考的对象。现在要对一个不断变化着的对象来进行验证，也没有一大段时间来设计自动化框架。我们怎么来保证质量呢？

敏捷QA的测试职责

在敏捷的团队中，质量是由团队所有人来保证的，我刚开始听到这句话就像听到敏捷宣言一样，知道这有道理，但具体怎么做呢？如果质量是团队的责任，那么专职的QA干什么呢？

首先我们来看在敏捷团队经常用来保证测试用例达到平衡状态的测试金字塔，简单来说我们可以把更多的测试放在单元和服务级别，因为这些用例更易维护和执行，运行效率也更高，可以参照Martin Fowler的TestPyramid。

在这个框架下，很容易让人产生这样的误解：

1、开发负责单元测试，不需要QA参与

跟组里的开发讨论过“是否需要QA参与到审查单元测试覆盖率”的问题，开发通常会觉得用处不大，因为有专门的工具比如：Cobertura， Jacoco, Istanbul等。这些工具的检查范围通常包括：

• 行覆盖率（line coverage）：是否每一行都执行了？

• 函数覆盖率（function coverage）：是否每个函数都调用了？

• 分支覆盖率（branch coverage）：是否每个if代码块都执行了？

• 语句覆盖率（statement coverage）：是否每个语句都执行了？

而QA的检查可以弥补单纯的代码级别的覆盖。比如异常处理和边界值的情况，代码级别的覆盖会检查语句是否执行了，但是不能检查这段逻辑是不是写了。下面列举出几种常用的检查方法：

• 等价类：把程序的输入域（所有可能的输入数据）划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中其他值。

• 边界值：边界值分析法是对等价类划分的补充，它是对输入或输出的边界值进行测试的一种测试方法。我们这里所指的“边界值”是相对于“输入等价类”和“输出等价类”而言的，稍高于其边界或低于其边界的一些特殊情况。

• 决策表：在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作，判定表很适合于处理这类问题。

• 因果图：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

有的QA会发现这些通常是用在黑盒测试里的方法，其实把这些覆盖尽可能的在单元或者服务级别来实现是一种既有效率，结果反馈又快，又可以直接作为回归测试的一种很好的途径。

在项目的实践中我们可以看到QA参与到单元测试的审查有以下好处：

1. QA可以审查单元测试的覆盖率，来调整单元测试以及后续接口测试和回归测试的覆盖率。之前做的项目都是开发独自写单元测试和接口测试，QA也独自写自动化回归测试，后来发现有很多的重复覆盖，这也是种浪费。如果能结对来做单元测试，是种更高效的方式。

2. QA可以更清楚代码对各个模块的影响，这样可以有针对性的设计回归测试，比如之前项目有个小的改动，QA没能在很短的时间进行回归测试，导致产品发布后遇到了问题。有人会说自动化覆盖所有回归测试不就行了么？理论上是这样的，但现实中有很多限制，只能通过手动验证来完成回归测试。这种情况下，精确定位回归测试的范围变得尤为重要了。

3. QA对系统构架、开发语言能有一个学习的过程，这有利于自动化回归测试的搭建。

2、开发更适合设计自动化测试框架和接口测试，因为他们写代码更有效率

如果说自动化测试和接口测试的目的是比谁写代码的效率更高，那么的确这些事情应该由开发去做，但是作为QA，参与其中的作用在于分析需求以及从客户的角度来设计用例。

敏捷团队越来越多的应用行为驱动开发（BDD）来覆盖基于服务和UI的测试。

QA会和PO，BA，DEV，UX一起合作，分析软件的需求，然后将这些需求写成用户故事。开发者负责填充这些故事的内容，测试者负责检验这些故事的结果。通常，会使用一个故事的模板来对故事进行描述。

故事的模板：

• As a 角色

• I want 特征

• so that 利益

比如：

As a mobile App user

I want to recharge the Mobile phone number with credit card 

so that I can have fee to give a call

每一个story有可能会有不同的场景，可以用下面的模板来描述在什么环境下发生了什么事情，结果如何。

• Given [上下文]

• And [更多的上下文]

• When [事件]

• Then [结果]

• And

比如：

Scenario: Recharge with Credit card successfully 

Given I logged into the Mobile App 

When I go to Recharge page

Then I can see the recharge option listed

And I can see the Mobile phone number input box listed

When I input the phone number

And I select the recharge option as "Credit card"

And I input the Credit card number

And I click the Recharge Button

Then I can see the "Recharge successfully" message shows

QA会和DEV一起合作来实现这些story的自动化测试，常用的工具:

• Cucumber (Ruby framework)

• SpecFlow (.NET framework)

• Behave (Python framework)

• JBehave (Java framework)

• JBehave Web (Java framework with Selenium integration)

• Lettuce (Python framework)

• Concordion (Java framework)

3、开发交互进行基于UI的测试就行了，不需要专门的QA进行测试

如果说基于UI的测试就是执行测试用例，那么的确不需要专职QA来做，但是在敏捷的团队中基于UI的测试大部分是以探索性测试来完成的。怎么设计好的探索性测试用例才是专职QA的价值所在。

有人说探索性测试就是手动测试，有的说是随机测试，有的说就是把自己当用户来使用软件的测试。

什么是探索性测试？下面是wikipedia上面的定义：

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1984,[1] defines exploratory testing as "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

看完这个解释更迷惑了，探索性测试到底是什么东西？

举个简单的例子，我们聚餐的时候有时候会玩猜数字的游戏，主持会写下一个数字，大家轮流猜，主持会提示大了或者小了。那么下一个人会根据这个提示来继续猜，直到有人猜中这个数字。这其实就是探索测试的原理，每次都会根据之前的结果来设计下次的数字，那个被猜数字就是defect，每一次猜测都是测试用例。如果你想用最少的次数来猜中这个数字，就需要有高效的方法，探索测试也是如此。

敏捷QA存在的价值

以上简单的描述了在敏捷团队中，QA在测试中的职责：

• 审查单元测试的覆盖率

• 和开发结对搭建基于服务和UI的测试

• 探索性测试

其实QA还有很多面向客户的职责，比如需求澄清以及产品演示，会在后续的文章去讨论。

随着敏捷的项目越来越多，对QA的需求不是越来越少，而是越来越高，QA需要像一个好的家庭主妇一样，能里能外，在团队内部能更好的平衡测试设计，在外部能更好的体现产品价值。在一个快速变化的时代，在持续快速交付的情况下保证质量是一件很困难的事情，解决这个问题就是QA存在的价值。

标签：单元测试,QA,framework,测试,专职,敏捷,洞见,团队
来源： https://blog.51cto.com/u_15127595/2737885