据说公司都认为他们在软件测试上的开销太大了。现在，如果对于一般软件开发来说，它的瓶颈是测试的话，那么裁减测试人员将会降低成本，但却给产品带了来质量差的风险。但是与开发人员，大量的测试人员似乎不切实际。到底是怎么回事，你怎么解决此问题？本文讲了四步流程助你降低测试成本。我已经验证过，很有效。

1.多看多听。

在办公室多逛逛，看一看其它测试人员。他们是否在操持着键盘进行工作；是否在运行软件，并安装它；是否在制定计划，更新它；或者他们在做其它的事情？做其它事情就是一个杀手。它可能支持其它的应用、对现在的生产版本进行修复、等待建立、等待服务器、等待决策者决定出什么是软件该做的事。这往往表现在花费大量的时间在电子邮件或煮咖啡、等待水凉或呆在其它人的小隔间、或者大量的网上冲浪上。

关键是测试人员被阻塞了。这些障碍不只是减缓项目进程；他们把测试变成一个非常昂贵的纸镇。所以我想进入这个行列，看看到底是怎么回事？

有时问题是系统性的。组织甚至没有意识到他们的大量员工正在坐等工作。当出现这种情况下，人员常常感觉他们需要掩盖这些时间。毕竟，他们会感到尴尬，遭到毁谤，不忙代表着人员冗余，这可能会导致裁员。

作为一个经理，我希望发现系统性的障碍并解决它。我会与测试人员一起工作，或者找出排除障碍的方法，或者把问题拿到台面上引起组织的注意，这样才不会浪费测试成本。另一个选择可能是重定向测试人员，让他们从事一些更可行的工作。

当我研究这本书时，得到一个最大的结论就是：三振出局。确实一直以来都有一个好的测试人员能够影响到项目的成果。即使迫于系统压力削减的测试人员，但是因为乐观向上的文化通常可能取得一些进步。

第二个方面是，有些人可能没有被阻塞，但只是不想工作，不想努力。如果你是管理者，每天在办公室逛两次，发现同一个人都没有在工作，并发现他们并没被阻塞，那么你就能识别出那些工作效率低的执行都了。你可以采用任何传统的措施来纠正错误，但是如果我是你，那么我会从经理开始。在这种情况下，又会怎样？

2.把障碍转移到高性能上。

一旦我们测试人员可能会取得真正的进步，那么我就要看看时间是如何分解的。他们是否真的在进行测试，运行实验，来检验软件的效果，或者他们存在做别的？开展会议、记录文档、设置测试环境、通过测试数据加载数据库，这样测试人员才会执行——这些事情都是偶然的。这些对手上的任务并不是必要的。

如果可能的话，我希望测试人员能记录下他们花费的时间，是用了一个星期还是两个来把工作分解成主要的类别。例如测试、安装、存档、会议及管理任务。

如果他们花了大量的时间在存档上，那么他们所做的就不是测试工作了。这对于安装和会议也是一样的。

去除会议、存档及安装并不是好主意，对于团队花费80%的时间在其它事情上，而非测试上，这种现象很常见。把它减少到60%—只拿出一小部分时间来做它—那么你就会事倍功半，而且不必有方法论，但要有一个工具，并让其它人进行培训。

诀窍就是哪些事情是浪费的就消除它。这可能需要一些毅力，要果断和明智。

我断定你就可以做这件事。但我从没说这是一件轻松的事。

3.加速测试进程。

谈到浪费，让我们来看看那20%时间，测试人员都在做什么。真正的问题是他们在做什么？

他们可能在努力重现漏洞，或探索相关问题，并试图描述它。也许测试人员正在写漏洞报告或参加一个分类会议。

注意，所有这些事情对件测试都不重要——他们之所以存在是因为错误的存在。对于这个问题，因为他们花费了时间，且是从真正测试中抢夺的时间来做这些活动。

忘记这20%。有些我与之工作的团队，他们甚至只花费5%的时间在真正的测试流程上——其余时间都花费在偶然事件上，而且他们只是因为漏洞的存在而存在。

我们可能不能消除漏洞，但是多数情况下，该软件在测试之前可以更好，这意味着测试人员可以花更多的时间在测试上，少一些时间浪费在沟通讨论问题工等待创建上。

从这点上，我想看看测试花了多长时间，并提出我们是否可以在他们进行测试前，使它创建的质量更好。

有许多方法可以做到这个。一种方法是简单地提供低质量初步构建给团队成员，作为一个工程问题，要求团队成员提出正确方案来解决问题。

4.去除超额的在制品（WIP）存货。在物理制造中人们明白超额的在制品库存是一种浪费；把钱放投入到没有价值的系统,上，另外在某些情况下，可能会导致打折销售和净空。一旦产品冲击廉价品商店，制造商可在每部分的产品都可能会亏钱——因为它使产品的批量生产巨大，超出市场承受能力，而不是一次性全部出售。

对于软件来说也是同样的。超额WIP就是浪费。当你的团队正在执行时，你可能想要减少流程工作，追求一个连续的工作流。这是一项挑战，可能会改变你对软件测试思考的方式——但这完全值得。

这个方法并不简单，且不是即时有效的。我可以在这诚实地表明：我工作过的公司，它们应用这些原则，已经从测试瓶颈转移到大量的测试质量保证时间和精力上了。

我工作过的团队已经雇佣了大量的开发人员而非测试人员，或者他们把一部分测试员转移到其它团队中，或者扩大测试规程的责任，包括更多的产品质量问题。