以前，我是個開發(fā)人員。我不喜歡這個工作，無盡的壓力讓我疲憊。我?guī)缀鯊奈锤杏X到自己的工作做得足夠好。我從未有過真正的休息。如果我沒做好，我們就可能超過最后期限，或者是打包了一個垃圾產(chǎn)品。經(jīng)歷了這些之后，成為一個測試管理者感覺就像是休假一樣。

測試同開發(fā)比起來，是一個非常模糊的工作——有很多的余地。我要做的僅僅是找問題。

我曾經(jīng)認為測試的職責(zé)就是找問題。

找問題很簡單，但是時間長了就會發(fā)現(xiàn)這樣很難讓人滿意。我想讓產(chǎn)品變得更好。

我曾是Apple一個400人團隊中的眾多測試專家之一。由于團隊名稱是軟件質(zhì)量保證（Software Quality Assurance），我們在質(zhì)量保證（QA）上的討論過比測試還多。一個管理者推薦了一本書，Philip Crosby的Quality Without Tears，以此來幫助我們看到自己在產(chǎn)品開發(fā)過程中更深層次的職責(zé)。這本書提到了“零缺陷”，于是我轉(zhuǎn)向了缺陷預(yù)防這一理念。“質(zhì)量不是測出來的”是我們的口號。

我曾經(jīng)認為測試的職責(zé)是保證質(zhì)量。

但是，測試人員并不能真正的保證質(zhì)量。首先，完美的質(zhì)量本身就是不可及的目標。質(zhì)量有多個方面，其中的一些就是沖突的。其次，測試人員并不創(chuàng)造質(zhì)量，所以保證質(zhì)量這樣的職責(zé)并不在我們的能力范圍之內(nèi)。如果我們把自己想象成質(zhì)量把關(guān)者，團隊的其他人就有可能傾向于為質(zhì)量少承擔(dān)一些責(zé)任，他們會認為有QA在保證著質(zhì)量——這樣如果產(chǎn)品不是很好，我們就會承擔(dān)主要責(zé)任。

除此之外，許多QA是通過定義流程和審查流程的執(zhí)行來發(fā)揮作用。問題是，這樣的一個方式很容易就會淪為關(guān)于質(zhì)量的說教，在響亮的口號和常見的“好的質(zhì)量是好的，不好的質(zhì)量是不好的”式的爭論中，QA所有的優(yōu)點都看不見了。這就是為什么很多開發(fā)人員把QA視為耳邊的噪音——只會另他們分心。

而我，從這種招人煩的角色中被解救了出來。經(jīng)理把我叫到一邊，告訴了我一個大秘密：一切都是為了風(fēng)險——不必追尋完美，只需找到一個足夠好的東西就夠了。這樣就把測試和質(zhì)量保證轉(zhuǎn)變成了一種項目的雷達，尋找敵人。我們在項目中是要快速的找到重要的問題，而不是每一個歷史階段中的每一個舊問題。

這深深的改變了我的思想。我不再像以前那么關(guān)注要在測試中達到盡可能全面的覆蓋，而是關(guān)注哪一部分真正需要測試，并評估未知問題的風(fēng)險。

考慮風(fēng)險使測試人員在項目中更加容易與其他人相處。關(guān)于質(zhì)量的討論變成了判斷哪些有影響，而不是糾結(jié)于誰想要完美。

我曾經(jīng)認為測試的職責(zé)是分析風(fēng)險。

風(fēng)險是很重要，但它仍然是一種抽象的概念，而且悲觀。一個開發(fā)經(jīng)理跟我說他不喜歡談?wù)擄L(fēng)險。“風(fēng)險聽起來很消極。我們不是保險公司理賠員，我們是企業(yè)家。我們勇于冒險。”他說的很在理。回報才是項目最重要的部分。難道對于測試，就找不到一個更全面和積極的觀點了？

當(dāng)然，測試的目的的確是發(fā)現(xiàn)問題、分析風(fēng)險、以及保證質(zhì)量，但是還有一種更本質(zhì)的方式來看待我們的職責(zé)：我們照亮道路。沒有測試，項目在黑暗中亂撞、被障礙絆倒、最后跌下懸崖。而測試會在需要的地方點亮火把，來幫助開發(fā)人員和管理者知道他們在哪、他們要去哪、還有他們什么時候能到達。

現(xiàn)在，我認為測試的職責(zé)是提供重要信息，來協(xié)助創(chuàng)造和運營優(yōu)秀的產(chǎn)品。這包括了發(fā)現(xiàn)問題、保證質(zhì)量、分析風(fēng)險、以及其他任何能夠幫助團隊了解當(dāng)前狀況的方式。

明天，我會怎么看待測試呢？

英文原文：http://www.dorsethouse.com/features/excerpts/exayebachv10n2.html

本文鏈接：http://www.cnblogs.com/twocats/archive/2012/07/24/2607148.html