Bug是什么？

　　警告：如果你有挑剔的眼光，并且你已经发现了写软件的唯一正确方法，你可能会感到被挑战。

　　新来的开发人员提交了代码，但是有bug。他们搞砸了代码，一个链接显示为明亮的、刺眼的红色，而不是公司要求的柔和的蓝色。你找到她，坐在一起，开始教导她测试的重要性，这时接到市场部的祝贺——因为最近一次发布，销售额上涨了了50%。

　　你知道唯一的修改是链接的颜色。

　　代码真的有bug？你还要诚实的把它回退？

　　更重要的是，这也是许多人搞错的问题：你从这件事得到什么教训？

　　为什么要测试

　　我们使用敏捷开发是希望改善开发过程，更好的分享信息，特别是更加方便频繁的获得反馈（这是一个反复发生的流程）。有趣的是所有的敏捷开发理论都要求使用者调整敏捷开发理论来满足个性的需求。我之前说过并且现在重复一下：你不能敏捷开发除非你自身是敏捷的。所以一些敏捷团队没有固定的迭代过程。其余的（大多数？）不搞结对编程。代码审查成了tricky bits（译注：不了解的词汇）和初级程序员。然而，尽管方法不同，这些公司往往做的很好。

　　但是他们都没有想要不做测试，他们没有想过。

　　在我们的“红色链接”例子中，如果进行了测试，那么就不会有50%的销售额增长。

　　我们大多数人很早就接触测试并且认为它不错。然后我们了解了TDD 并且意识到这就是测试的涅磐。 FIT testing 被那些FIT测试咨询机构过分的夸大了。现在BDD的情况也是如此：一些人兴奋的不得了，另一些人不以为意。我想这不过是另一次炒作，不是么？

　　但是测试是为了什么？从技术的角度来看，我们也许会争论说测试就是确保软件按我们希望的方式运行。但是这是最重要的事吗？请铭记一点就是：在一咕哝行代码里，所有软件都有bugs，所有的！

　　相反的，我认为更好的说法是所有软件都有无法预料的behavior.我们写测试是因为我们希望软件会按我们期望的那样运行。但是反过来，如果用户按我们希望他们做的方式去操作不是更好吗？你可以建立一个更好的捕鼠器，但是不能确保它们会钻进去。如果有些是从Digg或者一些技术灾害学习来的，那就会是这样：客户将会按他们该死的很乐意的方式去操作，无视你的软件是否是“正常工作”、你咨询的专家们和你举行了多少次讨论组。

　　与其说软件测试是客户行为的一种代理，还不如我们静下来为软件的客户好好想一会儿。

　　意外列表

　　考虑上面的“闪亮红色链接”的例子，再问一次：什么是bug？在那个例子中（不是随机选取的），可以简单说是一个软件bug，仅仅因为按意料外的行为。在这个例子中，是50%的销售增长。

　　现在，bug不再总是坏事情！我们可以用“意料外的行为”来思考——有时好，有时坏。

　　那怎么知道到底是好还是坏呢？

　　做一个意外列表。网站的500错误是坏的，而302呢？难说。也许你希望RAM使用率低于一定水平，或不像看到明显的销售额下降。也可能希望响应时间永远不超过$x毫秒。

　　列出所有明确不合预期的事件（例如：Facebook没有“like”按钮不属此列）并对所有这些行为进行监控。每当你修改或添加一些技术，请再次仔细检查你的不合预期列表。它们是不是最新的？你是否需要修改什么？

　　一些不合预期事情是可逆的（销售下降）且替代方法是好的。因此，也要监控这些。或许当一个版本提升了10%的响应速度时你想得到通知。

　　那然后呢？

　　嗯，这是伟大的但绝对不可能代替测试。你提交了两周的版本，内存消耗猛增，你疯狂地交换以致现在需要检查300行的文件差异。你很难在最佳时间找到内存泄露问题并且正常的测试经常遗漏它们（除了检查Test：：LeakTrace），但现在你要回滚一个巨大的修改然后检查3000行代码来找出你的问题。

　　因此你不必那么多。相反，你可以转换为不间断部署。在这个模型下，在准备好的前提下，可以把代码推送到产品里面。当然，假如你把它推送到盒子里面的话也很好，观察它，推送它到集群里面，观察它，然后把它推送到所有的服务器。通过多方面的监控，不寻常的情况常常出现的很快。并且你的内存泄露是30行的diff而不是3000行的diff.

　　你想处理那种情况呢？

　　（理所当然，我用内存泄露作为例子，但是这是一件经常花很长时间才显露出来的，而且我也懒得去改变这个例子。假装我过去写了5%的增加在404.）

　　在我的这个经验中，顾客对一些小异常简直就是很宽容，像大部分意料之外的行为都是一些诸如“图片不能显示”或者“这些查询结果排序是不正确的。”这些并不会趋向于导致灾难性。事实上，许多次这种异常的行为是被忽视的。就不良的事情而言，大部分时间意料之外的的行为将转变为中性或者不良。但是有时候他们也会转变成为好的意想不到的行为。假如你不试一试的话是永远不会知道的。

　　正如你所预料的，这个技术在“A/B testing”这本书中运用得很好。如果你有勇气查找非预期的行为而不是bugs的话，这本书将是下一个合符逻辑的计划。

　　注意：以上并没有排除编写测试（用例）。我看过“监控不合预期的事件”战略工作得非常好也坚信它可以结合软件测试进行工作。然而，测试软件是不同的，它更依赖客户行为而不是严格规范。因此，这篇博文的标题实际上是有点不对，它只是一个看待测试的不同想法。

　　而这正是这篇博文真正最有趣的想法：客户的行为比你应用的行为更重要。

　　原文链接：http://www.oschina.net/translate/how-to-be-agile-without-testing