只要技術好就不需要測試了...嗎？

軟體開發有一個傳說，越早發現問題最後產品的質量越有保障。軟體開發中保障質量的主要方法有兩個，Code Review 和測試。然而 Code Review 通常在代碼已經大致成型之後，而測試又在更靠後的階段，那麼在看似事後的手段中投入大量精力來保證軟體質量是不是本末倒置呢？

這些看似不合理的流程的設立其實有著更深層面的原因，如果一個人身體是車床，技術是工藝流程，軟體是車床上的產品，那麼人和機器有什麼區別呢？人不是完美的，人會犯錯誤，人有著複雜的心理變化，這些心理起伏會對整個結果產生影響。

一個簡單的例子，如果開發的流程引入了 Code Review 和測試，寫代碼的人就會寫的更加小心。我們對看不見的客戶碰到問題而抱怨可以視而不見，但被身邊的人指出來你這裡有問題就心裡亞歷山大，為了避免這種窘境就需要在寫代碼過程中注意這裡會不會被人揪出問題。所以這些看似後期的流程會在前期就發生巨大的作用，甚至他們最大的作用其實並不在測試過程中發現了多少問題，而在於有測試這件事對開發過程產生的心理影響。

車床上的產品在流入市場前也會經過測試，軟體測試和這種測試還有一些微妙的區別，由於軟體產品和人是直接相關的，而這種測試也不可避免的把人加進來，把人加入這個流程事情就複雜了。當找到一個 bug 如果交給機器人處理，機器會按照預訂路線處理。而如果是人本能反應會是抗拒的，儘管指出的是軟體的問題，而負責人產生的心理反應會是他覺得我有問題，我是不是很糟糕等一系列負面情緒，於是接下來本能的反應就是迴避掉或者轉移這個問題，諸如在我的機器上是好的呀，我測過沒問題呀，我沒有動過這塊呀，是不是別的組件有問題呀，這個就是這樣的不是問題......這樣面對 bug 的慣用句式。

同樣由於測試也是人，這種抗拒的答覆又會在測試的人身上產生反應，認為是對自己測試工作的否定，而接下來的反應很可能就連鎖循環下去了。日積月累下來，測試和開發的關係可能就不會太好了，本來雙方的理想工作模型是以軟體作為中介互相配合，到最後變為相互間直接的指責。這種相互指責其實還不是最差的結果，另一種可能就是雙方都是和氣的人不想惹對方生氣，開發想萬一讓他們測出問題來他們又得嫌棄我了，我這個功能不告訴他們偷偷上好了，測試發現問題想這個問題好想也不太嚴重不會影響客戶吧，告訴開發他可能心情不好，覺得我事多，要不就算了吧。這樣表面的和和氣氣下隱藏著更大的危險。

仔細想想這些事，發現軟體的質量還真不只是技術的問題，心理層面的問題會起著微妙而又舉足輕重的作用，而如果開發和測試雙方都能意識到這點，能跳出自己的心理定式，客觀的看待軟體中的 bug，了解對方反應背後的心心理動機，多一些理解，那麼整個流程的效率就會更高，軟體的質量也能得到更好的保證。

當然這些想法都是我在讀《顛覆完美軟體-軟體測試必須知道的幾件事中》想到的，推薦開發和測試還有基礎團隊的領導者抽空看一看。這是本頂著測試的名號講程序開發心理學的書，裡面會有些更有意思的例子，讀過後會有很多旁觀者清的體會，也會更深刻的理解那些技術表面下的心理本能。

更多文章，歡迎關注我的公眾號

http://weixin.qq.com/r/V0Pr82-ErTLSrSuQ9xZF (二維碼自動識別)