軟件測試工作中 QA 的角色和分工(3)

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

　　我們回頭來看，可以問：

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

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

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

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

　　問題：畫地為牢的分工

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

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

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

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

　　問題：無明確責任的分工

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

　　有時候出于種種考慮，人們會把一些善良但是能力有限的同事安排在一些位置上，扮演一些角色，例如“二讀”什么的?；蛘哂行┙巧褪怯梢恍┤苏紦?，但是大家對這個角色也沒有什么明確的要求。這是許多問題的根源。

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

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

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

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

　　。。。

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

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

原文轉自：http://www.uml.org.cn/Test/201306061.asp