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

　　理論上這都是非常有道理, 但是如果這些人如果沒(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)推廣, 客服都干了? 顯然不是。

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

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

　　· 充分授權和信任(Empower team members)

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

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

　　我猜想和踢足球類(lèi)似， 還是那幾個(gè)原因:

　　人太牛:

　　不世出的天才, 例如高德納寫(xiě)書(shū)的時(shí)候發(fā)現排版軟件不好用, 就自己寫(xiě)了一個(gè)。 也沒(méi)聽(tīng)說(shuō)他為這個(gè)軟件項目請了什么獨立測試人員。對了, 他不讀email 已經(jīng)很多年，有秘書(shū)幫他處理這些事 - 這也是一種分工!

　　事太小:

　　“我寫(xiě)了個(gè)小類(lèi)庫， 全部自己測試” 這當然不錯。

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

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

　　人不夠:

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

　　條件特殊:

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

　　引起網(wǎng)上討論的兩篇文章在這里:

　　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

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

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

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

　　c. 利用用戶(hù)的反饋和實(shí)時(shí)狀態(tài)分析 (比較過(guò)去一小時(shí)和上周同一時(shí)間的數據來(lái)判斷是否有bug).

　　d. 應用開(kāi)發(fā)商給Facebook 報bug. (開(kāi)發(fā)商其實(shí)比較不爽, 但是 FB 有時(shí)就是無(wú)預警地修改 API, 你除了趕緊報 bug, 還能怎么著(zhù)? )

　　e. 很多人自愿給Facebook 報bug, 這位貼主自稱(chēng)每月給他的前雇主報 13,000 個(gè)問(wèn)題. (沒(méi)錯, 是每月一萬(wàn)三千個(gè)! )

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

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

　　微軟是怎么做的呢?

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

原文轉自：http://kjueaiud.com