旧式测试已死
2013-08-05
（一） 看了20%之后写的
约在一年前，James Whittaker和Alberto Savoia在GTAC 2011上说Test is Dead，当时我的理解是，测试工程师这个角色没啥用了。但是看了这本书之后，才发现这样的理解有些偏差。Alberto的说法应该是，在敏捷以及互联网下，传统测试工程师已经没啥用了。
这边书前面几章是介绍google的测试现状的，最主要特点是：
1. 在一个几万人的组织里面，从事测试工作的工程师只有1千人左右。我查了一下这本书成书时google的人数，约在3万上下。假设从事feature开发的人有2万，那么这个测试开发配比将是十分夸张的。
2. Google在07年以前的代码都很混乱，很多该写测试的地方都没写。technical debt很多。
3. Google的迭代速度很快，并不像传统软件那样以几年为一个迭代周期。
这些特点很有趣。
我以前在不少网站上看到不少人在吵测试跟开发工程师的配比到底应该是1：1，1：5还是5：1，但甚少看到有人说1：20的。同时，我也很少看到有测试的人谈代码管理和单元测试的混乱状况的，一般测试的人谈的都是测试的事情，甚少说开发是怎么回事。最后，虽然经常听别人说敏捷，且说迭代速度快，但少有人说其迭代是weekly的。
针对这个现状，google的测试主管Patrick所做的并不是像一般组织那样搞人海战术，而是搞流程和工具。这点跟Lessons Learned in Software Testing所说的测试人员不要把自己当作过程改进人员完全相反。
为了把流程搞起来，Patrick 去弄了一个 CI 系统使得测试可以在每次check-in的时候做，让所有的SET(Software Engineer in Test)去辅助SWE(Software Engineer)写unit test，让所有的SWE感觉写 test 容易，且乐于写test。SET的职责反倒变成了Testing Service的提供者，而不是接受者。这点和我们公司不一样。
在传统公司（不幸的是，我的公司比传统公司还传统）里面，开发所做的测试最多最多就是到集成测试，且都做得很一般。所有的工具要么是公司买的，要么是开发自己造的。而测试和开发则是分离得相当远，测试工程师本身一定是测试者，而不是测试服务的提供者。
Patrick之所以这么弄，是因为他觉得，软件工程所交付的不是code，不是test，而是product，所以得让code和test集成在一起。
基于这个目的，在流程上，SWE才是所有测试脚本和测试的执行者，而SET是负责检查测试覆盖率，简化测试以及测试是否足够的保证者。
这点很颠覆。
Patrick把Testing当作产品的一项feature来做，这是很少有的。我当初在听James Whittaker的All that testing is getting in the way of quality时不懂的东西，在看了这书的前20%时突然明白过来。
因为我们把测试当作是某个人或者某个团队的工作，我们在开发产品的时候，就把quality认为是某个人或者某个团队的职责，从而使得开发者在写代码或者设计的时候就把质量给忘掉，毕竟还是有人可以接皮球的，何必费心呢。
在我从业的这3年里，这种开发不把质量当一回事，公司只知道交付feature的事情总是在发生，而我们的产品质量在这几年内基本没有任何变化。所谓的efficiency上的变化，也基本是公司印度那帮人吹出来的。是的，因为有人垫背，所以我们的开发不做单元测试；因为有人垫背，我们的开发写代码的时候可以直接透传而不必了解之前那一层的人写的是什么代码。
而某些测试工程师却费劲心思的想，某些bug在某些版本没测出来是所谓的“漏测”，但是从系统的角度来看，假设测试是一种测量，这不算是一种系统误差么？这种系统误差难道不是我们的流程所赋予的？
这本书的前20%也很奇迹的少提到所谓发现bug的方法，在众多的书籍和众多的blog文章中，没有一本或一篇是不介绍怎么“多发现bug”的，但试想一下，这跟在田野边踩牛屎有啥区别？完全是运气问题。
为了让踩屎少出现，只能让测试就是产品本身，而不是附加的东西。
另外，这本书一直在提First Class Citizen，令我想起James在其演讲中问的一个问题：“在座的，有人的工资比开发高的不？一样的？低30%？”结果只有少数人说是差不多，大部分人都是低30%。
一个工种是不是First Class Citizen除了在工资上可以看得出来，在平时讨论时也可以看得出来。在我这个行业，讨论技术细节和如何实施，那一定是跟测试无关的，且很多人不屑于跟测试讨论。为啥呢，问code不懂code，问需求又不如需求人员。
为了让测试的人能够只能批判开发写的代码和需求的问题，Patrick在招聘人的时候，要求一定要懂代码，懂需求而不是随便会按电脑就算是会测试了。WTF，这个世界估计就google能干这种事情了。
看看测试的现状，有多少公司不是因为开发工资比较高，怕他们浪费时间在测试上而请测试工程师的？连Joel on Software的作者在n年前的文章(http://www.joelonsoftware.com/articles/fog0000000067.html，参见最后一条。文章虽是十几年前写的，但是现状区别不大，测试的工资是高了点，但还是比开发低不少。)都说了，这可是便宜一堆钱的选择啊！也难怪现在越来越多的测试被外包给印度人。唉。
（二） 看了70%之后写的
看了约70%时，看到豌豆荚写了篇文章：从 QA 到 EP (http://www.wandoujia.com/blog/from-qa-to-ep)。这个世界遇到的问题总是相似了，我想所有公司的测试部门所遇到的问题都是相同的：看不到产出，做不了first class citizen。
最近在看这本书的时候，我又回去看了All that testing is getting in the way of quality这个视频，每次看的时候都觉得说得真他妈有道理。视频中，James说Quality的改变是因为有更好的工具，更好的语言，更好的软件重启恢复机制，更好的测试工具，而在这一路上，测试人员本身的贡献少得可怜。
说开发工具嘛，测试人员则少有使用这些工具的，少有测试人员开发这工具；说语言嘛，有多少测试人员开发过一款语言？说更好的软件重启恢复机制，这跟测试关系更小了；说到测试工具，则几乎只是测试人员在用而已。所以James觉得，测试人员并不是真的add value。
况且，实际上一家公司并不关心测试是谁做的怎么做的，他们只关心测试有没有做而已。既然如此，为啥不外包这些工作呢？
在这本书里面，每次看到TE的工作描述，就觉得他们真的是往开发方向走的，而不是纯粹的测试。比如他们的TE会想办法开发一两款有用的测试工具，比如Quality Bots， 来把自己的测试思想融入到工具里面。而那些手工测试，这公司在google plus上面做得更加纯粹，把一堆测试外包，然后再把测试给众包了，一个纯粹的手工测试人员都没有。
我并不是说这样做，其质量会怎么样之类的，而是James做了一个假定，那就是专门请回来的测试人员不一定能找到一样多的Bug，其价格也不一定比这些众包和外包便宜，如果是这样，何必请那么多贵的人回来做这些没啥意义的事情呢。
是的，许多人都说，衡量测试人员的价值不应该从bug的数量入手，但是如果不从bug的数量入手，怎么去说明呢？如果是从bug的数量入手，何不找些可以找更多bug却要更少钱的方法呢？
现在网上经常说有人帮google找Bug就有Money了，我每次看到那些新闻，然后看到那几千美金的奖励，我真觉得很便宜。
TE的职责有点相当于一个包工头，负责做dogfood，做crowd sourceing，负责给vendor找事情做，负责plan整个测试流程，偶尔去执行以下探索性测试，写一些测试脚本，写一下自动化工具，检查开发的流程有没有问题。
这不是一般公司对测试工程师的要求，所以这个职位跟我们说的测试职位不同。当然，很多公司那些便宜的测试人员，看起来更像是google请的vendor。
看这本书的时候，我跟我经理谈，说google的TE都不怎么做手工测试啊，也不搞什么重复劳动。我的经理说：“那是人家公司知道自己工程师的价值在哪里。”。难怪google可以做得那么好，人家的起点就跟我们不一样。
这本书有句话是经常讲的，那就是scarcity brings clarity，google做很多事情都尽量让资源稀缺一些，使得工程师不得不想怎么优化工作。但是在现实中，我的公司和我所知道的一些公司就不是如此了，都是在使劲堆人。测试没法完成是吧，我给你叫人上来；开发的东西写不完是吧，我给你加人；什么，单元测试写不完，那就不写了，我们再叫几个人上来写代码。到了最后，整个公司都是人，而做什么项目都好，几乎都是堆人。至于效率，呵呵。
查字典图书网
