現代軟件工程講義 9 測試 QA 的角色和分工

 

測試的角色 (Test) 要獨立出來么 ?

獨立出來的測試角色怎么才能發揮作用?

有些成功人士和成功的公司號稱沒必要有獨立的測試角色 (Test), 你怎么看?

 

 

最近又看到一些關於開發人員要不要負責測試的討論。 例如:

 

 http://www.aqee.net/on-testers-and-testing/

大多數的開發團隊並不需要一個獨立的測試角色。即使有一個，他的所有的開發時間比上所有的測試時間應該 >20:1。

[注: 這個翻譯就有錯誤, 原文指 開發: 測試 的比例應該 > 20:1 ]

 

我正好在寫相關的教案, 也來湊個熱鬧。

 

[這篇文章的一些事例來自於我曾經和現在的團隊。 希望這些例子不足以影響相關人物和團隊的偉大形象。   任何軟件團隊都會犯錯誤, 偉大的團隊有勇氣面對自己的錯誤並不斷改進。]

 

 

首先, 明確兩個概念:

軟件測試 (Test)：運用定義好的流程，工具去驗證軟件能實現預先設計的功能和特性, 工作的流程和結果通常是可量化的, 例如, 測試用例, bugs, 代碼覆蓋率, MTTF, 軟件效能的參數。 [注: 正因為流程和結果是可明確定義的, 可量化的,  很多測試工作可以自動化]

 

軟件質量保證工作 (Quality Assurance)：軟件團隊的成員為了讓軟件達到事先定義的質量而進行的所有活動，包括測試工作。

 

對於這兩個術語, 不同人有不同的定義,  有人認為它們是互通的, 在《現代軟件工程》的上下文中我盡量使用上述的定義.

 

測試的角色 (Test) 要獨立出來么 ?

回答:  首先,  我相信有分工是好事,  軟件團隊中應該有獨立的測試 (Testing) 角色。所有人都可以參與QA 的工作 (報告bug 什么的),   但是最后要有一個角色對QA  這件事負責。 不但角色要獨立，而且在最后軟件發布的時候, 必須得到此角色的簽字保證 （sign off）。我在微軟參與的項目都是這樣做的。

 

在開始論證之前,  先引用斯密特 ·亞當斯的 《國富論》 來暖場  (我沒讀過這本書,  直接從網上抄的)。

分工理論

亞當斯認為，分工的起源是由人的才能具有自然差異。… 假定個人樂於專業化及提高生產力，經由剩余產品之交換行為，促使個人增加財富，此等過程將擴大社會生產，促進社會繁榮，並達私利與公益之調和。 他列舉制針業來說明。“如果他們各自獨立工作，不專習一種特殊業務，那么他們不論是誰，絕對不能一日制造二十枚針，說不定一天連一枚也制造不出來。他們不但不能制出今日由適當分工合作而制成的數量的二百四十分之一，就連這數量的四千八百分之一，恐怕也制造不出來。”

 

分工促進勞動生產力的原因有三：第一，勞動者的技巧因專業而日進；第二，由一種工作轉到另一種工作，通常需損失不少時間，有了分工，就可以免除這種損失；第三，許多簡化勞動和縮減勞動的機械發明，只有在分工的基礎上方才可能。

 

引用 <http://baike.baidu.com/view/53445.htm>

 

 

我們看團隊形式的職業體育比賽, 各個位置的分工都很明確,  拿足球來說,  有專注進攻的, 有專注防守的,   但是在我的印象中,  那些偉大的前鋒大多數只管一件事 - 進攻。 亨利 （Thierry Henry）參加防守么? 

 

 

當然一些球賽也有沒有分工的時候, 原因 有好幾個:

事太小, 幾個小孩踢個半場。

無知, 小孩們剛開始玩球。

人手不夠,  一對一打籃球, 你要參與防守么?  沙灘排球，兩人都是全攻全守。

 

如果你的軟件團隊做的事情和上面的情況類似, 那當然不必分工。你們做的很可能不是商用軟件, 你的軟件團隊大概也不用受什么軟件工程規律的束縛。 (參見:  軟件工程概論).

 

任何產業產業成熟到一定階段的時候, 獨立的質量保證角色是不可避免的。團隊內部有QA 角色, 團隊外部也有獨立的QA 角色。

 

拿葯品和食品來做例子，  除了生產廠家自己的檢測之外,  這些產品還要接受行業主管部門相關機構的檢測和認可 (葯品檢驗, 食品檢驗), 才能上市。 在出現爭議的情況下, 還要第三方機構來進行測試或認證。

有人也許這樣建議:  

這些葯品都是葯廠同一批工人一邊制造一邊測試出來的, 特別有保證!  不用測了,  趕緊吃了吧!  

也許還有人這樣建議:

這個十字坡夫妻店的農家飯都是他們自己親手做的, 很可信， 咱們今晚就去吃飯住一宿吧。

 

我們每天經常使用的電子產品,  從大彩電到電影插座,  也經歷了很多團隊內部的和外部的測試,  請隨手拿過任何一個電器, 你會在背面看到密密麻麻的小字,  其中肯定有下列標記之一:

  

 

沒有這些標記的產品電子產品, 市面上很少看到。  

 

在軟件和互聯網產業, 目前沒有這些認證,  相反的,  倒是有“人肉認證” :

你想申請某個著名專業網站的賬戶或者郵箱, 但是又擔心這個網站對用戶信息的保護程度不夠。有人說, 沒關系的,  這個網站的創始人也用賬戶,  CTO , 總監什么的還經常發軟件安全博客,   賬戶一定是非常安全的！  這里不存在獨立的質量認證, 只能通過人肉 （創始人/CTO/總監）來認證產品的質量。  

 

其實這種認證未必安全…  （密碼門事件） （明文密碼事件）（郵箱密碼漏洞）

 

如果有第三方的認證 “此網站對用戶信息的保護程度是X級,  我們認證它不會明文存儲用戶密碼… ” 我就放心了。 在第三方認證出現之前, 我希望團隊內部至少有獨立的QA 角色, 來確保軟件的質量。否則我是不樂意使用這些軟件/服務的。

 

[補充一句,  互聯網服務的各種認證也在發展,  例如verisign 公司提供的各種認證。]

 

獨立出來的質量保證角色怎么才能發揮作用?

有了獨立的質保角色之后, 是不是萬事大吉了?   未必,  分工意味着一件事要分給別人去工作。讓別人做事, 並且依賴別人做出的結果,  這會出現一些問題。

 

問題：既然有專人負責, 那我就不用負責了!

生活中一個常見的歪理是,   既然有清潔工, 那我亂扔點兒垃圾算什么,  這才是他們工作啊!

 

盡管有專人負責QA 中的測試工作,  但是保證質量仍然是所有成員的職責。軟件團隊中的一些人往往在有意無意中忘記這一點。最常見的現象是開發人員寫好一個功能之后,  迫不及待地宣布成功, 然后希望測試人員去發現所有問題。 如果問題在發布后才被發現,  開發人員會說 – 測試人員怎么搞的， 這種bug 都沒找出來!?

 

某項目的某功能有重要的改進,  這個改進經過研究員的研究， 開發人員的設計,  美工的美化,  兩個開發人員的配合實現, 項目管理人員的督促,  測試人員的測試,  最后所有人都號稱做好了,  上線了！  為此,  我約了某個目標用戶給他做實地展示,  幾天后,  大家都到齊了, 開始演示。開始進行的不錯,  馬上最重要的killer  feature  就會出來了 …   噯,  預想的效果怎么還沒出現呢?   再試試,  還沒有?  各相關人員面面相覷,  大家小聲說: 

“我不是把那個新模塊給你了么？” 

“我就是照着那個接口實現的啊…”

“我不是已經交給那啥… ” 

“所有的bug 不是已經都搞定了么…”,

 

會議在尷尬中勝利結束了。

 

后來查問題的根源,  這個復雜的功能由於兩個模塊的接口在最后沒有同步,  某重要的參數被忽略了,  這個功能中最出彩的部分壓根就不可能工作!   那負責測試的角色怎么解釋 "所有測試用例通過,  同意發布" 的呢?  

這還是開發人員引以自豪的 “殺手級功能”  (killer feature),  那其它普通的功能是什么命運呢?

回過頭來, 我們可以問:

·         這件事真的要通過這么多環節么?   

·         測試人員真的知道最最關鍵的地方如何測試么?

·         在系統上線之后,  所有為這個功能感到自豪的人是否去實地測試過呢? 

 

 

一個開發人員應該負責下面“開發功能”右邊的幾個圓圈呢? 

 

 

問題: 盲目信任 “專業人士”扮演的角色

每個角色的水平不一樣,  軟件的質量往往受最差的角色的影響最大。我們團隊要為某軟件寫一段英語介紹文字,  團隊成員都是通過四六級英語考試的牛人,  可他們都很謙虛, 說要請一個專業的人士來寫不可。於是求了一個專業人士 ,  求了好幾次(專業人士很忙的),  在上市之前才得到專業的文案,  於是, copy/paste 幾次之后,  軟件就向全世界發布了.  

 

這個文案第一句就是熱情洋溢的設問句： "have you ever think about ..."  隨后還有幾處非常明顯的語法錯誤.  這個軟件吸引了不少評論文章,  有旁觀者說，  從介紹文字的幾處典型中國式語法錯誤來看,  這個軟件是由在中國的某分部搞出來的…

 

即使有專業人士扮演各種角色,  還得有專人獨立地檢查驗證質量。

 

我們回頭來看,  可以問兩個問題:

·         這件事真的要專業人士來做么?

·         專業人士做完之后, 誰來負責測試?

 

問題: 為了自己角色而做績效優化

分工之后, 每個角色為了自己的績效而優化,  會出現局部最優, 而全局未必最優的情況。

 

我們團隊的另一個wp7 的應用也要發布,   這次專業人士又出手了,  寫了175 個英語單詞的介紹, 極盡溢美之事,  而且找不到明顯的語法問題!   這的確是一種局部最優了。 但是完全沒考慮到用戶在小小的手機屏幕上有多少耐心讀完那么多形容詞和狀語從句。經過簡化,  我們把它減少到 78 個詞, 勉強能放進手機的兩個屏幕。

 

如果要以 "產出" 來評價某個角色的績效, 可以看看這個包裝設計的視頻:  

http://v.youku.com/v_show/id_XMzQ3NTUxOTU2.html

 

我們回頭來看,  可以問:

·         這些事真的要交給和項目無關的專業人士來做? 

·         當我們給專業人士介紹需求的時候,  是否花了足夠的時間讓對方理解我們要的是什么? 

·         專業人士做完之后,  我們要做什么樣的QA?  光保證沒有明顯的語法錯就夠了?

 

很多年前, 當COBOL 還是主流商用語言之一的時候,  我曾在一個在軟件團隊里負責測試工作。職責之一,  是寫各種測試用例, 來保證系統的代碼覆蓋率到達80% 以上。 做過實際項目的工程師都知道, 程序里很多語句是用來處理種種異常情況的, 這些情況大多數情況下不會發生。 但是這些語句如果沒有被覆蓋的話, 這個模塊的覆蓋率就會下降, 我就達不到80% 的目標。 所以我花了很多時間構造各種奇怪的測試數據, 把程序中的那些犄角旮旯都盡可能覆蓋掉。 至於這些犄角旮旯在實際中是否會發生, 對用戶的影響如何, 程序是否應該這樣設計, 我都不太關心。 只要覆蓋率達到 80%, 老子的活就干完了!

 

我這幾年做了不少內部的技術創新項目, 和許多技術牛人, 領域專家有愉快的合作。有幾個項目在演示的時候得到好評, 於是我們就想把它變成實用的工具。 這時，項目的重點從“演示酷技術”轉變為 “解決實際問題”。 有時候最酷的技術未必解決了所有問題, 這時我自然就建議用其它技術去補充。 但是有些技術牛人反而不樂意了, 幾經討論， 我理解了原來有人想使用 “純純的”， “完全是我自己的” 技術! 至於實用不實用是次要的, 關鍵是要用 “我的”  技術！  

 

問題: 畫地為牢的分工

在一個長期而復雜的項目中,  我要求所有新來的成員, 包括外包公司的新成員, 在加入團隊的時候,  先找到系統當前100 個數據方面的問題, 並用內部工具修復。我認為這能有效地讓新人了解系統的復雜性, 弱點, 和維護的流程。  外包公司的員工很爽快地答應了, 但是我們一些專家反而有不同意見。 專家認為, 外包公司的人是來做測試用例的設計,  所以不必做其它事情,  我們期望他們一上手就能設計出高質量的測試用例，不應該給他們那些低級的手工操作任務… 

理論上這都是非常有道理,   但是如果這些人如果沒有親力親為地在這個項目中做一些具體事, 他們怎么能 “設計” 出高質量, 有實際意義的測試用例呢?

 

有時分工導致鏈條過長, 信息丟失。 一個開發者對自己寫的程序有什么潛在問題還是很有感覺的,  有些問題可以用文字表述出來 (如果開發人員有耐心把文字寫出來的話),  有些問題是一些預感…  現在都交給別人測試了, 那好, 讓他們測吧, 我也懶得說了。

 

分工還可能會導致一個軟件的靈魂被切碎分給各個 "角色"， 每個功能都做得很賣力, 但是整體就是不太行,  明顯看出來是費了老大的勁給強行“集成”起來的。

 

 

問題: 無明確責任的分工

在我寫第一本書的時候,   編輯部告訴我他們會對書稿進行初讀, 二讀, 三讀 等流程,  每個環節要花幾天時間。 作為出版界的外行,  我理解這些都是QA 的階段,   等過了二讀的時間,  我就發信去問，  負責二讀的專業人士找到了什么問題了?  得到了語焉不詳的回答…   一個問題都沒找到?  但是從編輯部的回答來看,  二讀不二讀,  似乎沒什么影響。 其實這本書的小問題還很多， 在出版之后,  都陸陸續續被讀者報告了。

 

有時候出於種種考慮,  人們會把一些善良但是能力有限的同事安排在一些位置上, 扮演一些角色,   例如“二讀”什么的。或者有些角色就是由一些人占據着,  但是大家對這個角色也沒有什么明確的要求。這是許多問題的根源。

 

我們對這個角色有什么可以量化, 可以核查的責任要求? 

 

我們對“一本書的質量是X”的信心是 Y,  剛開始組稿的時候,  X 的取值范圍非常大 （爛書… 一般 … 好書… 年度大賣 … 永恆經典）， 信心也比較低。   經過每個一個QA  環節， 我們都應該把X 的范圍縮小,  把信心值 Y  提高。

例如:  二讀之后,  找到了20 個嚴重問題, 100個小問題,  因此我們有更大的信心認為這本書是一本爛書 （如果不做改進的話）。

再入: 二讀之后,  找到了 10 個小問題,  確信沒有更嚴重的問題了。  因此我們有更大的信心認為這本書是一本好書。

。。。

 

把 “書” 換成 “軟件”,  “二讀”換成 “測試”, 同樣道理。 

 

 

從上面舉的例子可以看到, 分工之后, 的確會產生很多問題。 但是解決的方案是什么呢?  是取消分工, 讓開發人員順手做測試人員的事情,  順便把項目管理, 美工, 市場推廣, 客服都干了?  顯然不是。

 

注意我們提到了 “角色”, 角色是有人來扮演的，如果一人扮演了“開發”的角色,  又能夠來扮演“測試”的獨立角色, 當然很好 。 但是條件是她要以“獨立”的心態測試， 而不是想: “這代碼就是我寫的,  哪會有什么錯…”  而草草了事。

 

那么獨立的測試角色怎么才能發揮最大作用?  從上面的壞現象中,  我們不難總結出來。 其實 MSF 原則都講到了。

·         充分授權和信任（Empower team members）

·         各司其職，對項目共同負責（Establish clear accountability and shared responsibility）

 

 

有些成功人士和成功的公司號稱沒必要有獨立的測試角色 (Test), 你怎么看?

我猜想和踢足球類似， 還是那幾個原因: 

人太牛: 

不世出的天才,  例如高德納寫書的時候發現排版軟件不好用, 就自己寫了一個。 也沒聽說他為這個軟件項目請了什么獨立測試人員。對了,   他不讀email 已經很多年，有秘書幫他處理這些事  - 這也是一種分工！

 

事太小:

 “我寫了個小類庫， 全部自己測試” 這當然不錯。 

 

我以前的一個優秀實習生后來一個人嘗試寫一些 UI 的控件, 寫得很高興的時候說了一句 “我現在軟件工程的原則都不管了…”為了玩得爽, 不妨打破束縛， 諸法皆空，挺好。

 

但是順水推舟, 推廣到所有情況,  從而得出 "程序員就應該自己測試，獨立測試不必了" 這樣的普適結論, 未免有點過。

 

人不夠:

那就自己動手多做一些事情, 也挺好。就像前面提到的,  一個人扮演多個角色，只要能入戲就行。

 

條件特殊:

    近年來, 軟件產業百舸爭流, 魚龍混雜, 在海里裸泳的弄潮兒也不少, 出現了種種類型的分工合作和開發模式。不在有些情況下(例如一窩蜂模式, 主治醫師模式), 強力的dev 是可以搞定很多事情。運用之妙, 存乎一心.

 

引起網上討論的兩篇文章在這里:

http://sriramk.com/blog/2012/01/testing.html

中文翻譯在: http://www.aqee.net/on-testers-and-testing/ 

 

http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

其中打分最高的回答來自前雇員  (Evan Priestley),  他總結了Facebook 這個公司為什么貌似沒有全職測試人員:

a.       全公司人員經常使用自己的軟件產品!   (如果你開發的軟件是航天飛行某控制模塊, 你怎么能經常使用呢? )

b.      使用 log 來分析問題可能出在哪里。  (我們的一些程序員寫程序都沒有log,  那大家看什么呢? )

c.       利用用戶的反饋和實時狀態分析 (比較過去一小時和上周同一時間的數據來判斷是否有bug).

d.      應用開發商給Facebook 報bug.   (開發商其實比較不爽,  但是 FB 有時就是無預警地修改 API,  你除了趕緊報 bug,   還能怎么着? )

e.      很多人自願給Facebook 報bug,  這位貼主自稱每月給他的前雇主報 13,000 個問題.  （沒錯, 是每月一萬三千個! ）

f.        最后這位前雇員還加了一句:  還有一個原因是, Facebook 大體上也不需要搞出太高水平的軟件。

 

當你的公司也能有 a) 到 e) 這樣的文化, 流程,  開發商和給力的前員工,  而且你的軟件“大體上也不要太高質量”你的確不需要什么全職測試人員! 

 

微軟是怎么做的呢? 

就像  MSF 原則 講的那樣,  有分工，有合作。

微軟開發測試主要有三種角色：

·         SDE: Software Design Engineer,  簡稱dev.

·         SDE/T:  Software Design Engineer in Test,  也寫代碼, 但是重點在測試。

·         STE: Software Test Engineer.

 

對於如何更有效地開發互聯網應用, 微軟 很多團隊都做過不少探索。 例如一些團隊嘗試把SDE 和 SDE/T 合成一體。 每個人都負責開發/測試/發布這一整套流程，根據我的觀察,  有好處， 也有額外的成本。

 

 

結束

一位網友說得好: 分工是社會和行業進化的結果。開發和測試其實是軟件工程的兩分支。不同的軟件／服務需要不同方式和程度的測試。獨立專業的測試等同於第三方代表客戶對產品認證。

 

拉拉扯扯這么多話,  團隊/個人/角色到底應該怎么辦呢?  我認為,    

·         在初始階段 （新項目,  團隊進入一個新領域, 人員剛進入一個項目）,  每個團隊成員都要盡量打通各個環節,  多負責， 把所有事情都搞懂,  培養通才。

·         當項目/產業發展到一定階段 （進入陣地戰的時候）,  要大力提倡分工合作,  培養專才。

·         把自己項目的架構和流程做好,  讓所有人都能比較容易地進行 Quality Assurance 的工作。

·         培養“大家都要做QA,  專人負責量化的Test,  有條件多做測試自動化”的文化。

·         要明白自己項目的特點, 人員的特點, 產業的特點。   避免照搬別人的做法。不要聽說某某偉大的系統的開發/測試比例是多少, 就哭着喊着也要同樣的比例…

 

思考題:

分工之后,  每人負責一小塊東西, 怎么能體現出個人的獨特而巨大的價值呢?  例如, 你剛到一個出版社, 領導讓你做 “二讀” 這份工作；  或者你剛到一個軟件公司, 領導讓你做  "測試"  這份工作, 你怎么能展現出你獨特的價值呢?

 

你在某團隊做測試，兢兢業業已經三年, 今天大家傳說公司認為開發人員應該做測試, 所以不需要專職的測試人員了。 你怎么想? 你能否做到:

1. 明確列出過去三年你對團隊的貢獻? 除了“認真執行測試用例”之外,  你對團隊整體的“質量保證”還有什么獨特的貢獻?
2. 有理有據地說明, 沒有專職測試人員, 項目會有什么風險?
3. 這三年的經歷在你的簡歷怎么寫出來? 你比三年前更容易找到工作么?

這三點搞不清楚的, 還是改行吧。