測試錯誤等於功能錯誤

Feb. 11 00:07~01:18

不知從哪一年開始，每年的農曆新年前後Teddy都會到台北的天瓏書局買幾本原文書回家當作自己的新年禮物。雖然去年新年買的書還沒讀完，但只要時間一到，還是忍不住手癢挑了幾本書回家。雖然現在網路上各種資訊很多，Teddy腦中很多知識的來源，還是來自書中。

這兩天在家讀了《How Google Tests Software》這本書的前兩章，有一種又喜又驚之感。喜的是書中所敘述關於軟體開發與測試的做法，和Teddy接觸敏捷開發以來（最早是XP，到近五年的Scrum、Lean）所理解與親自實踐的方法極為類似。當然在軟體規模與團隊人力上比不上Google所開發的系統，但這並不會妨礙有志之士「把軟體做對、做好」的決心。

喜的部分講太多就有吹捧之嫌，還是談一下驚的部分。請看以下幾句從書中節錄出來的話：

Quality is not equal to test. Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

品質並不等於測試。品質是藉由將開發與測試混合在一起一直到無法分出彼此（把開發與測試放入攪拌器中攪拌，一直到兩者徹底混和在一起，無法分辨彼此）。

這一句所要傳達的觀念，其實Teddy也提過了，只是句子沒有人家寫得好。真正讓「嚇到」Teddy是下面這一句：

Test is part of the functionality, and buggy tests are functional bugs and must be fixed. This ensures that new functionality does not break existing functionality and that any code modifications do not break any test.

測試是功能的一部分，測試錯誤應視為功能錯誤且必須被修復。這表示新的功能不能破壞原本正常運作的功能，而任何對程式碼的修改也不能導致測試失敗。

上面這段話，第一句最為重要，再讀一次：

Test is part of the functionality, and buggy tests are functional bugs and must be fixed.

***

雖然Teddy自認為在撰寫程式與帶領團隊的時候，測試與持續整合的功夫已經算是做的不錯了，但是Teddy對於「測試案例失敗」的警覺性，還沒有達到書上所說的境界。Teddy的經驗，當測試案例一多，尤其是有很多「自動化驗收（功能）測試」的情況下，要每次都讓這些測試案例100%通過，並不是一件容易的工作。測試案例執行失敗的原因很多，可參考《對付時好時壞的測試案例》系列文章一、二、三、四、五、六。如果把「測試當作是功能的一部分」，那麼測試失敗就表示功能還沒有完成。套句Scrum的術語，不能把工作（task）從Checked Out（In Progress）狀態移到Done。

回想起Teddy在帶領Scrum團隊的時候，雖然團隊的DoD（Definition of Done）有把「單元測試要通過」列入其中，但偶爾還是會有少數單元測試因為不明原因沒有通過，但卻沒有立即被修正。有時候這些失敗的單元測試一直被丟著沒人管，直到幾個sprint之後才被修正。雖然Teddy知道單元測試「理應」全部通過才對，但卻還沒有那麼高的警覺心，認定「測試錯誤應視為功能錯誤」。

***

依據《How Google Tests Software》書中的說法，當軟體建構的時候，如果測試案例失敗，建構系統會自動產生一筆錯誤紀錄（如同功能錯誤一樣，測試錯誤也會在議題追蹤系統中產生一筆錯誤紀錄），以此 強迫 提醒而開發人員必須要去處理。這也不失為一個好方法，不過Teddy覺得，在做此自動化之前，應該先幫團隊成員洗腦一下，讓他們相信：

測試錯誤應視為功能錯誤

團隊成員若是能接受這個觀念，當測試失敗之後的後續的動作，只要依據團隊解決功能錯誤的流程去處理即可。

***

友藏內心獨白：不要說團隊連功能錯誤也都不處理啊。