不用测试人员的五大(错误)借口

作者：周思博(Joel Spolsky)
译：Paul May 梅普华
Sunday, April 30, 2000
属于Joel on Software, http://www.joelonsoftware.com

1992年，James Gleick正和一个多虫软体的各种问题周旋。科学作家Gleick认为微软刚出的Word for Windows新版很_可怕_ 。他在星期天纽约时报杂志写了一长篇文章，这篇文章只能以激动来形容，整篇都在指责Word团队不理会客户的要求，交付问题如此多的产品。

稍后，他以地区Internet供应商Panix(刚好也是我的Internet供应商)客户的身份，要求提供自动排序并过滤其邮件的方法。提供这个功能的是一个叫 procmail 很神秘的UNIX工具，它的介面_连_ 最硬派的UNIX迷都觉得难用。

总之Gleick先生不小心在procmail里打错字，结果把他所有的信都删掉了。一气之下就成立自己的Internet连线公司。他雇用了Uday Ivatury当程式师，并且建立了Pipeline这个真的有点超越时代的公司：这是第一个有图形介面的商业Internet连线供应商。

当然啰，Pipeline也有它自己的问题。很早期的第一个版本没有使用任何错误更正的协定，所以很容易把资料弄乱或当掉。它就像所有的软体一样有臭虫。1993年我去Pipeline找工作，面试中问到Gleick所写的文章。「现在你已经身在篱笆的另一边，」我问道：「有没有稍微体会到创造好软体的难处呢？」

Gleick恼羞成怒。他否认Pipeline有任何问题，他也否认这个软体有和Word一样糟。他告诉我说：「约耳，总有一天你也会恨微软的。」他做了一年的软体开发而不再只是个使用者，这一年的经验却没有让他体会到无虫又易用的软体是多么困难的事，这实在令我有点震惊。所以我就回绝那个工作机会逃掉了。(Pipeline后来被一家世界上最奇怪的Internet供应商PSI买走，然后随随便便就被关掉了。)

软体有虫。CPU异常的守规矩，它们绝对会_拒绝_ 处理没有被明确教过的东西，而且通常会以最_孩子气_ 的方式拒绝。我的笔记型电脑在外头使用时常会当掉，因为它找不到本来找得到的印表机，多么像个_婴孩_ 。不过原因可能是某一行程式有个极微小却又很严重的问题。

这也正是你绝对要有QA部门的原因。每用两个程式师就需要一个测试人员(如果软体需要用于多种复杂的组态或作业系统时还不只)。每个程式师都应该和某一个测试人员紧密配合，尽可能频繁地丢出自己编译的版本给测试人员测。

QA部门应该要独立并拥有权力，绝对不可以对开发团队负责，事实上QA的主管应该有否绝权，可以阻止发行不合格的软体。

我第一份真正的工作是在微软；这家公司并不以高品质的程式_闻名_ ，不过它还是雇用了大量的测试人员。所以我曾经认为每个软体组织都会有测试人员。

虽然很多组织确实有，不过没有测试人员的组织还是多的令人惊讶。事实上很多软体团队甚至不相信测试。

你可能会认为，现在的经理经过80年代的品质狂热洗礼，又有各种无意义的国际「品质」认证(如ISO-9000)和「六个标准差」等术语，应该会了解高品质的产品才能获得高品质的生意。事实上他们都了解，其中大多数人已经尽量把它塞进脑袋，不过他们还是找出各种理由不用软体测试人员，而这所有的理由通通都是错的。

我希望可以对你解释这些想法的错误。如果你赶时间剩下的就别看了，直接算人头每两个全职程式师请一个全职测试人员就对了。

下面是我听过不雇用测试人员最常见的鬼叫：

1. 问题是懒惰的程式师弄出来的。

这种幻想的内容是这样的：「如果你请了测试人员，程式师就会马虎而写出问题更多的程式。不要请测试人员，就可以强迫程式师一开始就写出正确的程式。」哇！如果你会这样想，那你不是没写过程式，就是把写程式这回事完全想歪了。由定义来看 ，臭虫会出现就是因为程式师_没_ 看到程式码里的问题。通常就是需要其他人才看得到问题。当我还在Juno写程式时，每次都会用一样的方式执行我的程式。我会照我自己的习惯大量使用滑鼠操作。我们神奇的测试强者习惯有点不同：她比较常用键盘(而且会严厉地实际用所有可能的组合去测试使用介面)。这样子很快就会找出大量的问题。事实上有时候她还会说整个介面都不能用，而且是_百分之百不能用_ ，可是在我的机器上一切正常。当我看着她重现问题才恍然大悟。Alt键！你按住Alt键了！我怎么会没测到呢？

2. 我的软体放在网路上。即使有问题也马上就能修好。

哈哈哈哈！好吧，你说对了，用网路分发软体的确能比以往套装软体时代更快速的更新修正版本。不过即使把软体放在网站上，也别低估在专案冻结后修正一个问题的代价。一来你可能在修正第一个问题时产生更多的问题。更糟的是如果你检讨发行新版本的程序，就会了解在网路上丢出修正版是个相当昂贵的建议。更别提会让人因为有以下感觉而造成坏印象了：

3. 客户会替我测试软体。

啊，令人害怕的「Netscape防线」。这家可怜的公司借着独特的「测试」方法严重伤害了自己的声誉。他们的测试方法是：

当程式帅写好一半时，不经任何测试就把软体发行到网路上。

当程式师_说_ 完成时，不经任何测试就把软体发行到网路上。

重复做六到七次。

把其中某个版本称为「最终版」

每次当c|net上爆出一个丢脸的问题时就发行.01、.02、.03版。

这家公司是「广泛beta」这个点子的先驱。意思是让_数百万_ 人下载这些多虫的未完成版本。最初几年几乎所有Netscape使用者都在用某个抢鲜版或beta版。结果大多数人都认为Netscape软体的问题实在很多。虽然最终版通常问题都极少，可是Netscape已经让多到离谱的人用过多虫的版本，所以大多数人对该软体的_整体_ 印象都很差。

另外让「客户」来测试的重点在于让他们找到问题然后由你来修正。不幸的是，Netscape或任何其他地球上的公司都没有人力，可以处理两百万客户的问题回报并找出真正重要的问题。当我要填报Netscape 2.0的问题时，问题回报网站一直当机，根本不让我回报(不过反正问题回报最后都会丢进黑洞)。可是Netscape并没有学到教训，现在6.0「抢鲜版」的测试人员就在新闻群组里抱怨，说问题回报网站还是没办法送出报告。那么多年了！还是老问题！

不过我敢打赌，在这些多得要命的问题回报中，绝大多数都在讲相同的5到10组很_明显_ 的问题。里面可能还埋有一两个有意思又难查的问题，是某人千辛万苦才成功送出的。不过反正没人会看这些报告，所以也就等于不见了。

这种测试型式最糟的一点，就是公司会得到非常差的印象。当Userland推出主力产品Frontier的第一个Windows版时，我去下载并开始照着教学操作。不幸的是Frontier当了好几次。我完全照着教学上面的指令逐一照做，怎么样都没办法执行两分钟以上。我觉得Userland可能连 最基本 的测试都没做，根本没有确认_教学_ 是能动的。产品品质低落的印象让我有很长一段时间不再碰Frontier。

4. 有资格可以胜任的人都不想做测试人员。

这是个很沉痛的理由。好的测试人员非常难找。测试人员和程式师一样，顶尖高手和一般水平的人相差_一个量级_ 。Juno有一个测试人员Jill McFarlane，她找到的问题是_其他四个人合起来_ 的_三倍_ 。我是真的算过，绝对没有夸大其辞。她比普通测试人员的生产力好12倍 。当她离职时，我写了封电子邮件给执行长说道：「我宁愿只有星期一和星期二让Jill帮忙，也好过让QA团队其他人全部一起测。」不幸的是，这么聪明的人大都容易对日复一日的测试感觉厌烦，所以顶尖的测试人员通常只待三或四个月就会换工作。这个问题唯一的解法就是面对然后想办法处理。下面列出几个建议：

把测试当作技术支援的下一个晋升工作。测试或许很沉闷，不过绝对比用电话处理愤怒的使用者好，而且可能也是消除某些技术支援人员骚扰的方法。

允许测试人员上程式设计课程拓展职业生涯，并且鼓励较聪明的测试人员，运用程式工具及脚本语言开发自动化测试套件。这比不断重复测试相同的对话盒要有趣多了。

要有顶尖测试人员经常流动的认知。积极的进行招募以保持稳定的人员流入。不要只因为暂时满额而停止招募，因为总会有下一波好景气。

找寻「非传统」的工作者：找聪明的青少年，大学里的小朋友还有退休人士来兼差。你可以用两三位顶尖全职人员再搭配一群趁暑假赚学费的Bronx Science(纽约一流高中)学生，建立出一个效果惊人的测试部门。

雇用临时人力。如果请10个临时工进来拿你的软体来玩个几天，就会发现很多很多的问题。里头可能会找到两三个测试技巧不错，值得签约转成全职人员的人。要先有心理准备，里面有些人可能做不了测试人员；这时只能请他回家再继续找新人。这也正是临时人力仲介的功用。

下面这种方法_无法_ 处理这个问题：

千万不要对来工作的电脑科系学生打歪主意，说什么「所有人都要在QA部门磨练一阵子才能去写程式。」我看过太多例子了。程式师_没法子_ 当个好的测试人员，而且还会因而损失好的程式师，而这就更难找了。

终于到了，这是人们不雇用测试人员的头号笨理由：

5. 我请不起测试人员！

这是最笨而且也是最容易揭穿的理由。不管测试人员有多难找，还是比程式师要便宜，而且便宜多了。另外如果不请测试人员，就得让程式师自己测。再来如果你认为测试人员大量增加不太好，就想想这件事的代价吧：年薪十万美元的明星程式师受不了有人要他「在发行前留几个星期测一测」，而换去比较专业的公司。光是为找新程式师而付给猎人头公司就够你一年请三个测试人员了。吝啬请测试人员是如此的划不来，我实在不懂为什么有这么多人认不清。