QA如何减负？把工作给Dev干!

2017年注定不平凡！

停更了这么久，因为家里遇上些难事儿。生亦不可怕，死亦有何惧？然而最折磨人的是，却是世间竟有超越生死的事情。这些日子，我反复思考, 假如生命只剩最后一天，我们该如何活？假如知晓自己仅存有限却日益艰难的时光，又该怎么活？我想到了海伦凯勒，想到了史铁生，想到了霍金......然而，每天晃晃度日，泪流满面，为无力替家人分担而痛苦，为无法改变现实而痛苦。

第一次真正理解“平安健康”才是上天给予我们最大的恩赐，它比任何荣誉、金钱和财富更为弥足珍贵。或许我们所习惯的、以为与生俱来的东西，恰恰是别人求之不来的。我们不知道，自己其实多富有。不该再沉迷于痛苦，感恩自己所拥有的一切，珍惜每一分一秒的时光。不再睡懒觉、不再毫无意义的熬夜、不抱怨天气、满足于一顿饱饭、好好锻炼身体、努力工作学习、想做的事就立即行动、想爱的人放手去爱。

于是，想做的事，此刻，我正在做......

---

昨天给team成员做了一个有关测试的Session, 大家的反馈极好，于是写出来，希望能给QA和Dev一些不同的提示。QA如何减负？如何将自己从重复的功能测试中解脱出来，去从事自动化测试、性能测试、安全测试以及更高级别的探索性测试？最好的办法就是培养开发人员的测试意识，教会开发人员做测试。

为什么开发人员要提高测试意识？

在敏捷团队中，每一位团队成员都应该为产品质量负责，站好自己的那班岗，才能够真正高质量地交付产品。敏捷团队对每一位成员都有很高的要求，QA要懂代码，开发人员要懂测试。为什么要培养开发人员的测试意识呢？我们来看一下测试金字塔。

很明显，越到金字塔的顶端，所投入的成本就越高。是不是不易理解？举个简单的例子：

Story：#111、#112、#113、#114

开发人员：Dev A，Dev B

测试人员：QA

Dev A领取Story #111，假定产生3个defects，修复一次通过。我们来计算一下Dev自测发现defects和QA发现defects的时间成本：

第一种方式：Dev未自测，QA发现3个defects

Step 1: Dev开发story花费: 3h；

Step 2: QA测试花费: 1h；

Step 3: QA发现Defect 3个，反复验证并编写defect清单，每个defect花费：0.5h；

Step 4: Dev修复每个defect花费: 0.5h；

Step 5: QA回归每个Defect花费:0.5h。

(暂且忽略Dev和QA在进行其他story的过程中被中断的时间)

Story #111总共花费时间: 3+1+0.5*3+0.5*3+0.5*3 = 8.5h

第二种方式：Dev自测发现2个defects，QA发现1个defect

Step 1: Dev开发story花费: 3h；

Step 2: Dev自测花费: 0.5h；

Step 3: Dev发现Defects 2个，修复每个defect花费：0.5h；

Step 4: QA测试花费: 1h；

Step 5: QA发现Defect 1个，反复验证并编写defect清单花费：0.5h；

Step 6: Dev修复defect花费: 0.5h；

Step 7: QA回归Defect花费:0.5h。

(暂且忽略Dev和QA在进行其他story的过程中被中断的时间)

Story #111总共花费时间: 3+1+0.5+0.5*2+1+0.5+0.5+0.5 = 7h

很显然，总计节约1.5h的时间成本。当然，这只是个简单的例子，只为说明开发人员自测的重要性。

在敏捷开发的测试阶段中，Dev如何做QA

我们来看一下，敏捷开发涵盖以下6个阶段的测试：

第一阶段.单元测试：无疑是由开发人员进行，针对代码的测试。用来测试函数、方法或模块。每个单元测试都有独立的输入和输出，不相互依赖。理论上讲，单元测试用例要在coding之前写好。

第二阶段.迭代测试：这是敏捷开发独有的模式。BA将一个个feature，拆分成独立可交付的story卡，并按照优先级排放在迭代中。开发人可以自主选取当前迭代的story卡，进行理解和编码，功能完成之后交付QA测试。QA测试通过，defect修复通过，这个story卡就可以关闭了。在这个过程中，除了coding, 开发人员要学会功能测试，将defect在交付QA测试之前灭掉。

第三阶段.回归测试：敏捷开发旨在将一个个feature拆分成多个独立可交付的story卡，因此很可能一个feature要贯穿好几个迭代。因此对于开发人员来说，当feature完成之后，做一个回归测试，也就是将整个feature所包含的所有story卡连接起来做一个集成测试。

开发人员在这三个测试阶段参与测试，既能有效的帮助QA进行质量把关，又能提高自己的代码质量。

人人都是QA

说了这么多，归根结底，是要教会开发人员如何做测试，人人都做QA。

在敏捷项目中，开发人员应该从两个方面学习测试：

1. 严格按照Story的Acceptance进行测试，保证基本交付功能的准确性；

2. 学习测试的基本知识，从产品惯有的维度去测试；

我们以Web和移动APP的测试为例（不适用与其他产品），需求分为功能性需求和非功能性需求，测试也相应地划分为功能测试和非功能性两个维度:

1. 功能性测试：

2. 非功能性测试：

当然，一些性能和安全方面的特性，会应客户的需求，建成独立的story卡，因此有很严格验收标准。然而，除此之外，还有很多需求层面涉及不到的性能、安全等测试，这就需要发挥脑洞，运用自己的工作经验啦。作为一名开发人员，理解以上的非功能性测试就足够了。

还在等什么？快快去教会你们的Dev做测试吧！ 

封面图片来自于ThoughtWorks公司内部