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

　　我們團隊的另一個(gè)wp7的應用也要發(fā)布，這次專(zhuān)業(yè)人士又出手了，寫(xiě)了175個(gè)英語(yǔ)單詞的介紹，極盡溢美之事，而且找 不到明顯的語(yǔ)法問(wèn)題!這的確是一種局部最優(yōu)了。但是完全沒(méi)考慮到用戶(hù)在小小的手機屏幕上有多少耐心讀完那么多形容詞和狀語(yǔ)從句。經(jīng)過(guò)簡(jiǎn)化，我們把它減少到 78個(gè)詞，勉強能放進(jìn)手機的兩個(gè)屏幕。

　　我們回頭來(lái)看，可以問(wèn)：

　　1、這些事真的要交給和項目無(wú)關(guān)的專(zhuān)業(yè)人士來(lái)做?

　　2、當我們給專(zhuān)業(yè)人士介紹需求的時(shí)候，是否花了足夠的時(shí)間讓對方理解我們要的是什么?

　　3、專(zhuān)業(yè)人士做完之后，我們要做什么樣的QA?光保證沒(méi)有明顯的語(yǔ)法錯就夠了?

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

　　問(wèn)題：畫(huà)地為牢的分工

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

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

　　有時(shí)分工導致鏈條過(guò)長(cháng)，信息丟失。一個(gè)開(kāi)發(fā)者對自己寫(xiě)的程序有什么潛在問(wèn)題還是很有感覺(jué)的，有些問(wèn)題可以用文字表述出來(lái)(如果開(kāi)發(fā)人員有耐心把文字寫(xiě)出來(lái)的話(huà))，有些問(wèn)題是一些預感…現在都交給別人測試了，那好，讓他們測吧，我也懶得說(shuō)了。

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

　　問(wèn)題：無(wú)明確責任的分工

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

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

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

　　我們對“一本書(shū)的質(zhì)量是X”的信心是Y，剛開(kāi)始組稿的時(shí)候，X的取值范圍非常大(爛書(shū)…一般…好書(shū)…年度大賣(mài)…永恒經(jīng)典)，信心也比較低。經(jīng)過(guò)每個(gè)一個(gè)QA環(huán)節，我們都應該把X的范圍縮小，把信心值Y提高。

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

　　再入：二讀之后，找到了10個(gè)小問(wèn)題，確信沒(méi)有更嚴重的問(wèn)題了。因此我們有更大的信心認為這本書(shū)是一本好書(shū)。

　　。。。

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

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

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