 《轉載》獨孤木專欄 之 Software Quality Assurance |       |
《轉載》Software Quality Assurance （上）
如果你在逛街時，發現有件款式非常流行的衣服，看了覺得十分滿意，
可是衣服破了一個洞，還有一些污痕，你覺得有點訝異，找來賣衣服的
小姐，想要問個仔細，她卻對你說：『這件衣服雖然這裡有一個洞，那
裡的顏色也不太對，不過你既然急著要，那就先拿回去穿吧。過兩個月
以後，我會把針線放在我家門口，你自己到這裡來一趟拿回家自己縫一
縫吧。雖然是這樣，這件衣服，還是不二價。』你會怎麼做？
1.乖乖付錢，兩個月後很高興地去拿針線
2.殺價
3.叫會殺價的人去買，再叫別人補好了以後，再拿來穿
凡是在這個性向測驗選擇1的人適合當軟體工程師，選擇2的人會在企業
裡面擔任採購，選擇3的人，則是可以順利當上主管。至於會把售貨小姐
痛扁一頓的人，可以考慮到反微軟聯盟工作。
這種莫名其妙的事情，在購買一般的消費品時，是不會發生的，最少在
已開發國家不會。可是軟體公司趕時間做出勉強可以運作的軟體，接著
靠著好奇又喜歡嘗試新鮮事物的使用者的奉獻與測試，再靠著強勢手法
行銷，就不斷地推出更新版，升級版來賺更多的錢，這好像已經變成了
這個業界的常態。經過多年的洗腦，大部分的人都已經默默地接受了『
只要是人開發出來的軟體，就必然會有bug』這樣的觀念。
遇到這種狀況，有些人就會想要把以往流行過的品管觀念，像是TQM
(Total Quality Management)，拿來用在軟體開發上。不過依照這個業
界的特性，頭字語怎麼可以採用其他領域的名詞呢？我們應該自己發明
一個。所以就有了類似SQA 軟體品質保證(Software Quality Assurance,
SQA)這樣的名詞出現。
關於Software Quality Assurance呢，我個人並不是這方面的專家。所
以關於SQA跟TQM，或是其他各個令人頭痛的頭字語之間到底有什麼細微
的差異，我是一概不知。不過沒關係，根據統計數字顯示，大多數的讀
者也不是這一個領域的專家。這就讓我有機會可以扮演先知的角色。如
果你剛好是這個領域的佼佼者，建議你快快翻過去，不要看得太認真。
對於很多人來說，Software Quality Assurance指的就是軟體測試。以
我看來， Software Quality Assurance最少還包含了怎麼去做review，
怎麼建立一套良好的標準開發流程，怎麼進行相關檔案的版本控制，遇
到高severity(優先權)的defect時，要怎麼進行處理，建置開發與測試
的環境時，又要考慮什麼，以及怎麼樣去收集並解讀defect的資料…等
等。
(※作者註：defect跟bug不太一樣，例如有些人可能會覺得螢幕上的字
不夠大，想要叫你把字型調大一點，像這種狀況就是一個defect，可是
這並不是程式有什麼錯誤(bug)。不過呢，除非你想要考狀元，否則大
部分時候你可以不去管它們有什麼不同。以我來說，我覺得最大的不同
是當你在討論專案的狀況時，如果用了defect這個字，會讓你看起來非
常的專業。)
不過不可否認，要把Software Quality Assurance做好，最重要的工作
還是測試。所以我會從軟體測試這個主題開始聊起。
***測試***
我開始從事軟體工作時，我以為軟體公司的主管，應該都是這個業界的
資深前輩，所以對於軟體應該要怎麼發展，應該有很深刻的了解跟體認
。不過經過了這幾年，我發現好像全然不是這麼一回事。至少在測試這
件事情上來說，我遇到的主管真是形形色色都有。
最天真的主管，通常會像是發現新大陸一樣的問我這樣的問題：『我們
為什麼要做測試呢？我們要的東西不是軟體嗎？只要程式設計師夠努力
，夠小心，應該就可以做出沒有bug的軟體，為什麼還要花錢養人去做測
試呢？把錢省下來，我們去養超級優秀的程式設計師，找超強的駭客嘛
，幹嘛花那麼多心血去做測試呢？』
我總覺得，為什麼要做軟體測試其實就跟人類為什麼要戴保險套，是同
樣的道理。男人會戴上保險套，並不是這個動作會帶來什麼快美難言的
愉悅，我們要的是性。不會生小孩，不會得性病的性。做軟體測試也是
一樣。我們會做測試，並不是我們喜歡測試帶來的感覺，而是我們怕小
蟲蟲會帶來我們不想要的結果。測試並不會讓一個本來已經正確的軟體
，變的更為正確。所以總會有人認為，幹嘛要養專門的測試人員呢？
主張不用測試人員的主管，還是只要請程式設計師自己測試就可以的主
管，其實就像是主張透過性交中斷法來避孕一樣。會有這樣思考模式的
主管，基本上就跟想要哄騙女朋友上床，卻有沒有準備保險套的十五歲
少男一樣。『我的自制能力比較強，只要我們小心一點，在蟲蟲快要跑
出來之前，就先把它抽出來，就不會懷孕了。』同樣的道理，只要程式
設計師小心一點，就不會有小蟲蟲了。
下回你遇到這樣的主管，你就直接想到十五歲的思春少男就對了。採用
這種策略通常都要付出可觀的代價，就像避孕失敗就得選擇墮胎或是當
小父母一樣。當然，當你發展的軟體沒啥價值時，有沒有測試人員其實
都沒差。大自然會自動淘汰不適合生存的物種。
另外一種天真的想法是，只要我們用了超強的程式設計師，就不會有bug
了。相信這種論調的人，或許也會認為下面的推論很有道理。
甲 ：醫師，怎麼可能？我女朋友怎麼會懷孕呢？這一定不是我的孩子。
醫生：怎麼說？
甲 ：我每天坐在電腦前面超過十二個小時，又長時間的熬夜，每天還都
穿著牛仔褲，依據醫學報告，我應該會不孕才對啊。怎麼有可能懷
孕呢？
醫師：……
相信擁有良好的天賦，再加上長時間接受輻射線的照射，以及超長的工作
時間，小蟲蟲就會比較少。如果這個理論成立的話，我們也不需要避孕了
，只要轉行來寫程式就好了。寫程式的功力比較好，並不表示就沒有小蟲
蟲。況且有很多問題，並不是來自於程式設計師本身，從使用者到系統分
析師，以及系統設計人員，每個環節都可能有問題。就像不孕並不一定都
是女方的責任一樣；凡是長時間在電腦前面工作的人都有可能要負點責任。
關於這個問題，其實程式設計人員也要負一部份責任。主管的愚蠢，多半
是因為無知所造成的；可是程式設計人員的自我膨脹，卻是讓這個問題更
加惡化。我不只一次遇到所謂的超級程式設計師，他們的特點是動作很快
，或是腦筋很好，每個人都自信可以移山倒海：『如果有人寫程式會有bug
，那一定是他們能力不夠好。像我們能力這麼好，寫出來的東西一定不會
有問題。所以我寫的程式是不會有bug的。或者因為我比較強，所以我寫
的程式bug比較少…你找任何測試人員來挑戰我的智商，簡直就是在侮辱
我！』
很多人寫好程式以後，就自以為天衣無縫，根本就不想繼續測試。所謂的
單元測試，常常都是虛晃故事。說來慚愧，我小時候也是其中的一分子。
像我還很年輕的時候，每次寫完一篇文章，總是覺得自己真是妙筆生花，
文思泉湧。任何人要是嘗試修改我完美的遣詞用句，必定會遭到我無情的
奚落與鄙視。
後來長大一點以後，就發現用新注音用久了，有時候電腦還是會胡亂組字
，我沒有在第一時間改回來，就把文章寄出去了。害我每次印出來看到自
己寫錯字，都會想要叫電腦用微軟新注音罰寫一百遍。打字習慣了，寫起
字來也是魯魚豕亥，多所舛誤。隨著年月的增長，隔了一段時間回去看自
己的各種議論時，慢慢也領悟到自己所學還是有所不足。所以現在對於各
方的指正，就會比較虛心接受。
寫文章都已經是這樣了，更何況是寫程式？程式發生錯誤，並不是因為智
商的關係，也不盡然都是因為一時的粗心。大部分時候，是因為design沒
做好，或是在開發時想法上不連貫，或是對於要解答的問題沒有想清楚。
很有可能寫程式寫到一半，心愛的女友忽然打電話來說要分手，以致於心
神喪失，無法專心致志的把程式寫完；也有可能是房東臨時打電話來要收
房租，得要跑出去避難；也很可能是隔壁的貓咪在思春…反正造成bug的問
題很多，沒有一樣跟你們的智商有關。你們自己編。
而一個負責任的程式設計師，就應該體認到寫程式時，可能會面臨很多干
擾，所以任何時候要把程式release出來前，都應該要自己做好把關的角色
。沒有經過自己的單元測試，驗證你的程式確實是work的，不應該把程式
release出去。
當主管也認知到，超強的程式設計師所寫的程式也會有bug以後，就已經往
上成長了一層。畢竟軟體需要測試，這跟人需要買保險是一樣的道理。可是
測試到底包含什麼呢？他們的了解就不是很深入了。所以他們唯一會做的就
是：『不斷地重複一些陳腔濫調，可是沒有任何實際的動作。或是想出一些
不太有用的把戲。』
『品質非常重要。所以CEO對於品質非常重視，他特別把今年定位成品質年…』
『Quality is number 1.』
『測試非常重要。所以你們要努力地測，用力地測，想盡辦法地測。』
『品質是所有東西的根本。只有良好的品質，我們才能獲得客戶的認同…』
好吧，對這些主管來說，反正測試就是一件很重要的事情，你可以為這麼
重要的事情設計一些標語，印在馬克杯上，還是做做海報貼在牆上，平時
訓話時，加強宣導測試或者是品質的重要性，或者是把測試跟品保，指派
給一個專門的人，這樣子主管的工作就告一段落了。
每次遇到這樣的主管，我就會想起下列連續劇的對白：
父親：你怎麼這麼不小心？怎麼會把人家的肚子給搞大了？我不是一再跟
你講，要小心嗎？我不是一再跟你講，要記得戴上保險套嗎？
兒子沒有說話，可是音響要傳來他內心的聲音：『你每天只會講這個，可是
我連買保險套的錢都沒有，怎麼戴啊…』
或許這個兒子並不了解何謂reuse的真諦，他應該要多加了解使用OOAD的好
處。不過很多主管，就跟這個父親一樣。總是覺得測試或是任何品質保證
的工作，應該只要加強宣導就可以了，並不需要另外花錢，或是花太多資
源來做這樣的事情。這應該是寫程式的人，應該要負起的責任。畢竟問題
就是你們造成的，你們自己不找出來，自己不解決，還要推給誰呢？
另外一種很有趣的觀念，就是測試雖然很重要，可是我只要安排人去測就
好了。而且最好測試人員就是實際的使用者。畢竟，還有誰對這個領域更
了解呢？所以他們的想法，就是請這些測試人員，用力的測，大力的測，
想盡辦法的測。反正就是做monkey test就對了。下回遇到這樣的主管時，
記得買些香蕉。
好吧，我們並不是生活在蠻荒時代，這個業界還是有很多了解為什麼要做
測試的主管。只是通常測試在台灣不怎麼被重視，連帶地也比較少人想要
往這個領域鑽研與發展。結果常常就是測試人員嚴重地編制不足，地位低
落。
測試人員的不足通常有兩種現象，一種是程式設計師要兼著做測試，另一
種則是程式設計師把測試的責任，通通推到已經不足的測試人員身上。
讓程式設計師兼著做測試(不是只有unit test，是連後面的integration
test, system test喔。)其實是一種最笨的做法。眾所皆知程式設計師的
薪水很高，人數很少。所以是一種稀有的資源。請程式設計師兼著做測試
，就跟拿純金去打造一隻馬桶刷一樣。除了不好用以外，價錢一定很高就
不要提了。
請原作者去找出自己的錯誤，是很困難的。因為每個人思考都會有盲點，
那就是為什麼需要由不同的人從不同的觀點進行測試，才有辦法找出潛在
的問題。
另一個現象則是程式設計師把測試的責任，通通推到已經不足的測試人員
身上。這是因為有很多公司，除了測試人員嚴重編制不足，連程式設計師
也是嚴重不足。所以程式設計師的心態就是，我只要寫完就好了，所有的
測試，都不是我的責任。
測試是需要程式設計師與測試人員彼此緊密配合，密切溝通的活動。如果
一個程式設計師的心態不正確，就會讓這個工作很難順利地推展下去。
軟體測試其實是一門很高深的學問，要進行測試之前，需要先做出詳細的
規劃，把要做哪些種類的測試，要收集哪些資料，怎麼收集，遇到問題要
怎麼判定，怎麼追蹤問題…通通都規劃好寫出來，寫成測試計劃。接著則
是需要依據分析或設計文件，仔細去想想要怎麼測試，要用什麼樣的資料
來進行測試，要用什麼程序來進行測試…。把這些都想好了以後還是要寫
下來，寫成測試個案。接著除了去執行原先設計的個案以外，還得要針對
問題進行分析與追蹤，並且要管制好各個版本的系統…還好我在這本書中
，只想提提我所看到的一些問題，至於每件事情該怎麼做才比較好，那是
下一本書的課題。
測試其實是確保品質的最後一道防線。眾所周知，越晚發現問題，解決的
成本越高。早期發現，早期治療，治愈的機會越高。要怎麼樣才能早期發
現問題的徵兆呢？那只有靠review了。
***Review***
早期發現，早期治療，聽起來非常有道理。然而開發軟體牽涉到心智思考
模式的交換，這也讓review這件事，變得相當困難。很多人對於review的
看法，就是找超人幫忙用X光眼睛看一看，就可以早期發現問題。問題是
如果超人這麼管用的話，為什麼他不是一開始就加入這個專案？為什麼有
這麼多的超人，還是有這麼多失敗的專案呢？
或許我們可以看看下面的例子。
客戶甲：布魯斯，為什麼你們在專案組織裡面列了超人的名字，可是我們
一直沒有看到超人的出現？
布魯斯心想，(那是因為吉娜為了讓專案的組織看起來稱頭，才列了超人的
名字，超人這麼忙，要對抗邪惡拯救整個地球都來不及了，怎麼會有時間來
拯救我們呢？)於是布魯斯說：超人會在需要幫忙的時候出現，我想，除了
一開始在設計系統架構時，會需要超人的指導。我們會請超人來參加review
，幫我們先期找出系統潛在的問題。
客戶甲：能夠這樣當然是最好了。
三個月後。
客戶甲：布魯斯，為什麼超人還是沒有出現？我們review了這麼多次，超人
還是沒有出現！是不是我們這個專案比較不重要？
布魯斯(超人本來就沒有時間了，這該如何是好？)：我想超人會在我們需要
幫忙的時候出現。目前我們的成果應該還算可以。
客戶甲：誰給你這種錯誤的印象！我覺得我們這個案子已經陷入很大的危機
之中。我會跟吉娜好好討論這件事情，是不是你們覺得我們這個專
案比較不重要？如果你們的resource調度有問題，我來幫你解決。
辦公室內，吉娜正在跟客戶甲通電話。
吉娜：是，是，是。沒有問題。我會負責解決。您客氣了，好的，好的。沒
有問題。拜拜。(掛掉電話。)布魯斯，客戶甲剛剛打電話來。你說該
怎麼辦才好？
布魯斯(還不是你捅的紕漏？還問我怎麼辦？)：我想我們還是得要請超人去
露露臉，不然這件事可能不容易解決。
吉娜：不可能，超人現在正在全力對抗邪惡的外星壞蛋。我目前可以提供的
支援就只剩下靈犬萊西。
布魯斯(陷入極度的恐慌)：可是他是一隻狗！而我們沒有人懂得小狗在叫什麼！
吉娜：這就跟你從美國找consultant過來一樣嘛。上回我們找那個拿美國護
照的俄國佬，他的英文不是沒幾個人聽得懂？客戶甲不是也被唬的一
楞一楞嗎？
吉娜顯露出智商突然下降至90以下的表情。布魯斯無法抵抗沒有邏輯的思考，
只好屈服在吉娜的淫威之下：我還是覺得要想辦法請超人過來露露臉？
吉娜：如果超人有空的話，當然沒問題。(是啊，如果太陽從西邊升起來的話。)
三天後。
布魯斯：我知道超人會用光速飛行，不過他現在因為照射到克卜頓星球隕石
的光線，所以身體變得非常虛弱。目前正在調養身體之中。(有本事
，你殺到醫院去抓他出來啊。)沒關係，為了支援這個專案，我們公
司還是派遣了相當資深的顧問，這位是靈犬萊西，它具有多年的專
案經驗。
靈犬萊西：汪汪汪。
布魯斯：我想靈犬萊西可以參加我們的review。如果我們討論的過程，他發
現了任何問題，他會隨時提醒我們。
靈犬萊西：汪汪汪，汪汪汪，汪汪汪。
客戶甲：……
一般在進行review時，有分為形式上的審查，以及實質內容的檢討。形式上
的審查，多半在於審查文件格式是否符合標準的格式？開發流程是否依據標
準的流程？除非你相信，因為你寫的文件格式不符合標準格式，所以跟你共
同開發的夥伴們就沒有辦法看懂這些文件，否則這些審查最大的意義，只是
在於把review這個法定的程序給走完。本身當然沒有什麼立即的價值。
實質內容的檢討，當然會有意義的多。可是這裡就牽涉到，參與review的每
個人，事先必須對於要被review的事物有足夠的了解，要被review的文件要
事先發給所有與會人員，並且各個review的人最好要事先將意見寫出來，提
供給其他參與會議的人。
光這一點就很難做到了。所以一旦進入這麼細節的討論，無可避免的是開發
時間一定會拖的很長，而要找到這麼適當的人選，並不容易。而這些人是否
有時間可以仔細地推敲，詳細地審閱，來找出潛在的問題，都是蠻關鍵的因
素。要能達到有效的review，人選其實是最關鍵的因素。你要找的人，是否
擁有足夠的能力，如果這個人有這樣的能力，在時間上又是否可以配合？這
其實都會影響review所可以達到的效果。
大多數時候，所謂的review都是在蓋橡皮圖章。很多人就是想找個強人背書
，表示這個案子有被強人看過了，也提出一些問題，不過大致上看起來還好
。然而對於真正有問題的專案來說，不是找不到適當的人來review，就是這
些人沒有時間。有時候則是整個review流於形式上的審查，並沒有什麼真正
的發現。不過這還不是最令人惋惜的結果。
即使你找到對的人，也發現了問題，這樣就達到了review的目的嗎？當然不
是。Review除了要找出問題，最重要的還是要針對問題來提出解決方案。然
而有很多時候，解決方案並不是那麼容易可以實行。
超人：經過我用X光眼睛照射，加上我從克卜頓星球所學來超越凡夫俗子的知
識，我覺得整個架構都有問題，整個high level design跟low level design
都需要重新來過。不然就算是現在開始implement，以後問題還是會層出不窮
。
吉娜想，(我們已經花了十二個人月在做design，這個穿著內褲的傢伙在開玩
笑吧？)：超人，難道你不可以看出最關鍵的問題，我們針對問題來解決就好
了？可不可以不要動架構？
超人：我會用光速飛行，可是要不動大架構，就可以解決這個問題，這只有上
帝才行。
吉娜心想，(這種只懂得技術的人，果然腦筋比較死一點，讓我來點醒他一下)：
超人，其實客戶現在只是想要你幫忙看一下。你的想法我已經知道了，可是這
個問題如果要這樣解決的話，公司會受到很大的打擊。你要不要在review的結
果這裡盡量地輕描淡寫，反正現在問題很大我們已經知道了。詳細該怎麼做，
我會跟project team討論過以後，再請布魯斯好好規劃以後再跟你討論。畢竟
你這麼忙，有這麼多事要去做。(等老娘把你擺平了以後，就趕快找人去
implement了。我又不是被嚇大的。Design重新來過？怎麼可能？我今年考績
不就完蛋了？聽說ERP部門正在找主管，我跟Michael好好談談，趕快調過去，
這個燙手山芋就可以丟給別人了。Design做完了，超人也背書了，剩下有問題
，就是implement的人做的不好，跟我是一點關係都沒有。)
超人：好吧，整個文件的格式看起來還是不太對。我會請整個design team在
每個文件之前加上一張比較好看的封面，跟詳細的目錄，最後要加上一
個漂亮的封底。這樣才符合我們公司定出來的文件標準。
從上面的例子看來，review的時機還是很重要的。如果解決方案的成本太高，
專案經理很有可能會採取比較沒有效果的方案。因為這看起來可能對於目前的
衝擊比較小。只是對於目前衝擊比較小的方案，不見得對於整個專案的衝擊比
較小就是了。
跟review相同，系統測試一樣與很多執行面的細節有關。設計出來怎麼進行
測試，或是找了人來負責進行測試，並不會保證你的問題就會就此解決。我
認為測試的成敗，會跟下一節的主題很有關係。
(待續)
|
2003-10-15, 17:58
