Bug是什么？
警告：如果你有挑剔的眼光，并且你已經(jīng)發(fā)現(xiàn)了寫軟件的唯一正確方法，你可能會感到被挑戰(zhàn)。
新來的開發(fā)人員提交了代碼，但是有bug。他們搞砸了代碼，一個鏈接顯示為明亮的、刺眼的紅色，而不是公司要求的柔和的藍色。你找到她，坐在一起，開始教導她測試的重要性，這時接到市場部的祝賀——因為最近一次發(fā)布，銷售額上漲了了50%。
你知道唯一的修改是鏈接的顏色。
代碼真的有bug？你還要誠實的把它回退？
更重要的是，這也是許多人搞錯的問題：你從這件事得到什么教訓？
為什么要測試
我們使用敏捷開發(fā)是希望改善開發(fā)過程，更好的分享信息，特別是更加方便頻繁的獲得反饋（這是一個反復發(fā)生的流程）。有趣的是所有的敏捷開發(fā)理論都要求使用者調(diào)整敏捷開發(fā)理論來滿足個性的需求。我之前說過并且現(xiàn)在重復一下：你不能敏捷開發(fā)除非你自身是敏捷的。所以一些敏捷團隊沒有固定的迭代過程。其余的（大多數(shù)？）不搞結(jié)對編程。代碼審查成了tricky bits（譯注：不了解的詞匯）和初級程序員。然而，盡管方法不同，這些公司往往做的很好。
但是他們都沒有想要不做測試，他們沒有想過。
在我們的“紅色鏈接”例子中，如果進行了測試，那么就不會有50%的銷售額增長。
我們大多數(shù)人很早就接觸測試并且認為它不錯。然后我們了解了TDD 并且意識到這就是測試的涅磐。 FIT testing 被那些FIT測試咨詢機構(gòu)過分的夸大了。現(xiàn)在BDD的情況也是如此：一些人興奮的不得了，另一些人不以為意。我想這不過是另一次炒作，不是么？
但是測試是為了什么？從技術(shù)的角度來看，我們也許會爭論說測試就是確保軟件按我們希望的方式運行。但是這是最重要的事嗎？請銘記一點就是：在一咕噥行代碼里，所有軟件都有bugs，所有的！
相反的，我認為更好的說法是所有軟件都有無法預料的behavior.我們寫測試是因為我們希望軟件會按我們期望的那樣運行。但是反過來，如果用戶按我們希望他們做的方式去操作不是更好嗎？你可以建立一個更好的捕鼠器，但是不能確保它們會鉆進去。如果有些是從Digg或者一些技術(shù)災害學習來的，那就會是這樣：客戶將會按他們該死的很樂意的方式去操作，無視你的軟件是否是“正常工作”、你咨詢的專家們和你舉行了多少次討論組。
與其說軟件測試是客戶行為的一種代理，還不如我們靜下來為軟件的客戶好好想一會兒。
意外列表
考慮上面的“閃亮紅色鏈接”的例子，再問一次：什么是bug？在那個例子中（不是隨機選取的），可以簡單說是一個軟件bug，僅僅因為按意料外的行為。在這個例子中，是50%的銷售增長。
現(xiàn)在，bug不再總是壞事情！我們可以用“意料外的行為”來思考——有時好，有時壞。
那怎么知道到底是好還是壞呢？
做一個意外列表。網(wǎng)站的500錯誤是壞的，而302呢？難說。也許你希望RAM使用率低于一定水平，或不像看到明顯的銷售額下降。也可能希望響應時間永遠不超過$x毫秒。
列出所有明確不合預期的事件（例如：Facebook沒有“like”按鈕不屬此列）并對所有這些行為進行監(jiān)控。每當你修改或添加一些技術(shù)，請再次仔細檢查你的不合預期列表。它們是不是最新的？你是否需要修改什么？
一些不合預期事情是可逆的（銷售下降）且替代方法是好的。因此，也要監(jiān)控這些。或許當一個版本提升了10%的響應速度時你想得到通知。
那然后呢？
嗯，這是偉大的但絕對不可能代替測試。你提交了兩周的版本，內(nèi)存消耗猛增，你瘋狂地交換以致現(xiàn)在需要檢查300行的文件差異。你很難在最佳時間找到內(nèi)存泄露問題并且正常的測試經(jīng)常遺漏它們（除了檢查Test：：LeakTrace），但現(xiàn)在你要回滾一個巨大的修改然后檢查3000行代碼來找出你的問題。
因此你不必那么多。相反，你可以轉(zhuǎn)換為不間斷部署。在這個模型下，在準備好的前提下，可以把代碼推送到產(chǎn)品里面。當然，假如你把它推送到盒子里面的話也很好，觀察它，推送它到集群里面，觀察它，然后把它推送到所有的服務(wù)器。通過多方面的監(jiān)控，不尋常的情況常常出現(xiàn)的很快。并且你的內(nèi)存泄露是30行的diff而不是3000行的diff.
你想處理那種情況呢？
（理所當然，我用內(nèi)存泄露作為例子，但是這是一件經(jīng)常花很長時間才顯露出來的，而且我也懶得去改變這個例子。假裝我過去寫了5%的增加在404.）
在我的這個經(jīng)驗中，顧客對一些小異常簡直就是很寬容，像大部分意料之外的行為都是一些諸如“圖片不能顯示”或者“這些查詢結(jié)果排序是不正確的。”這些并不會趨向于導致災難性。事實上，許多次這種異常的行為是被忽視的。就不良的事情而言，大部分時間意料之外的的行為將轉(zhuǎn)變?yōu)橹行曰蛘卟涣肌５怯袝r候他們也會轉(zhuǎn)變成為好的意想不到的行為。假如你不試一試的話是永遠不會知道的。
正如你所預料的，這個技術(shù)在“A/B testing”這本書中運用得很好。如果你有勇氣查找非預期的行為而不是bugs的話，這本書將是下一個合符邏輯的計劃。
注意：以上并沒有排除編寫測試（用例）。我看過“監(jiān)控不合預期的事件”戰(zhàn)略工作得非常好也堅信它可以結(jié)合軟件測試進行工作。然而，測試軟件是不同的，它更依賴客戶行為而不是嚴格規(guī)范。因此，這篇博文的標題實際上是有點不對，它只是一個看待測試的不同想法。
而這正是這篇博文真正最有趣的想法：客戶的行為比你應用的行為更重要。
原文鏈接：http://www.oschina.net/translate/how-to-be-agile-without-testing