品質是檢驗出來的，還是設計出來的？

一般而言，軟體測試是為了提高軟體的品質，而因應軟體開發的不同進展，開發者常會採用不同的測試方法來控制軟體產出的品質。然而，前一陣子，James O. Coplien 提出軟體開發是宗教信仰驅動的產業卻指出了對軟體測試的質疑。

首先，Coplien 提到了做不做測試驅動開發（TDD，test-driven development）或是驗收測試是一個錯誤的問題，因為軟體開發應關注在品質上，測試所能涵蓋到的品質問題只是片斷而零散的，它是在軟體產業中所知當中，最沒有效率的方法。

然後，Coplien 用「宗教信仰」來批評 TDD 的追隨者，認為他們是盲目的而未加以審慎地思考它可能並不是最佳的實踐方法，同時對於任何的批評也會招致他們的情緒反應，他指出這已經變成一個宗教信仰的問題了。

Coplien 認為要用系統工程的角度來思考問題，也就是如何用最有成本效率的方式把工作做好，而新時代的敏捷運動卻一貫地脫離這些實務。他認為表面上加緊進行簡單的設計看起來很好，但一旦將這些設計放在一起卻會看到它們彼此是片斷而零散的。

不過，Coplien 的觀點在軟體開發社群中卻引來了不少的批評，有人提到對自己親身體驗到的成功所懷有的熱情是不應該與教條主義或宗教信仰混為一談的，更有人認為 Coplien 的觀點缺少事實根據，並且他的主張是懷有個人偏見的。〈软件开发社区“宗教信仰”之争风波未息〉總結這些批評提到：

Coplien 的核心觀點並沒有問題，只是選用了錯誤的論據進行了錯誤的證明。這也提醒我們要以冷靜理性的態度對待問題，否則便有可能在遠離一個極端的同時，走向另一個極端。

同人認為這個宗教信仰之爭是沒有意義的，甚至會覺得 Coplien 對軟體測試的批評讓我覺得很困惑，他想要表達的是什麼？他說要關注於思考而不要對新技術或熱門詞彙亦步亦趨，這個我同意，但從他的文章看起來，他似乎也不由自主地建立了另一個宗教信仰。

特別是「做 TDD，還是驗收測試？」這個問題更令我疑惑，這兩者明明是不同層面的問題，拿來比較有何意義呢？我不認為它是如 Coplien 所說的偽命題，相信應該還有更深的一層意義。

於是，同人換個角度來思考問題，驗收測試與 TDD 有何不同？一個是由客戶端來驗證軟體是否符合他們的品質要求，另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地，這個問題的重點並不在測試，而是「開發者應該自己驗證程式，還是該仰賴客戶來幫你找程式缺陷？」。換言之，就是我們常聽到的一句話：品質是檢驗出來的，還是設計出來的？

進行軟體測試的目的，最主要是要防止軟體在客戶端產生功能失常（failure）的情形，但它並無法完全確保程式本身絕無瑕疵（defect）存在。一旦軟體測試涵蓋面不足時，交付給客戶的軟體就很容易會產生品質的問題。然而測試的涵蓋面要夠廣，軟體開發所需的開發成本與時間就要增加，所以與其靠檢驗來控制品質，還不如把設計做好。所以，品質是設計出來的，而非檢驗出來的。

不過，雖然品質並不是檢驗出來的，但軟體要具備足以信賴的品質，卻不能省略測試。舉個例子來說，不管開發者如何確保他的開發所產出的品質，驗收測試是絕對不可能省略的，否則客戶是很難信任軟體是合乎他們需求的。良好的軟體設計可以減輕測試的負擔與壓力，但它絕對無法否定軟體測試的價值。

所以，品質的問題並不是測試效率太低；而是開始測試的時間拖得太久，使得分析設計階段的缺陷不斷地擴散而使開發人員窮於應付。例如開發者在設計的過程中有沒有去思考設計驗證的問題，還是把這個責任推給後續的品管作業，例如 code inspection，或是各種形式的審查作業？

這個答案無關乎方法論本身的優劣，而是關乎開發者面對問題的態度，這對品質有著直接而深遠的影響。沒錯，我們需要專注於思考，但思考的重點並不在用那一種檢驗方式比較有效率，因為那樣我們將會落入品質是檢驗出來的迷惘當中。而是應該思考，對這個問題為什麼我會這樣設計？我如何驗證它是可行的？有沒有可能它會無法解決問題或造成其它我沒有想到的問題？

軟體工程本來就是實務中的理論，測試先行從來就沒有遠離過軟體工程的實務範疇。所以用不用 TDD 其實並不重要，每一種方法都有它的假設與限制，要認清問題，然後按照實際狀況來予以實踐並調整，陷於主觀的意氣之爭其實是沒有意義的。不同的方法沒有宗教信仰的問題，而是只有如何有效地加以運用來達成目的而已。因此，要讓軟體滿足客戶品質的要求，思考的重點是在於確認設計的實踐，而不在於方法論的偏見呀。

Please follow and like us: