不要測試它

  做為一名測試人員,我們也許會問我們自己很多問題:

  ● 我們可以立即執(zhí)行的好的測試是什么?

  ● 我將要使用的測試方法是什么?

  ● 這是一個Bug嗎?

  ● 我已經(jīng)測試完成了嗎?

  但是我們之中會有多少人提出以下的這些問題呢?

  ● 這個組件需要一直被測試到嗎?

  ● 需要由我來測試它嗎?

  ● 如果它不工作,誰會去在意它呢?

  在我看來,我們提出的問題中和以上三個問題類似的還遠(yuǎn)遠(yuǎn)不夠。可能這是因?yàn)槲覀円呀?jīng)被告知要測試一切東西。甚至我們的一部分人會在其質(zhì)量團(tuán)隊(duì)中有一個流程,要求某個人把每一個組件都貼上“已測試”的標(biāo)簽。我們對待測試像一個常規(guī)的工廠程序,我們甚至有時候引以自豪的說…

  “我是測試工程師。因此,所有的東西都需要被測試…由我來做…即使非測試人員已經(jīng)測試過了…即使我已經(jīng)知道它將會通過測試…即使需要一個程序員告訴我怎么去測試…我必須測試它,沒有例外!”

  這類想法可能會讓測試人員有一個壞名聲。由于欠缺思考的過程導(dǎo)致它強(qiáng)調(diào)了測試的重要性,而不是給一些人提供有價值信息的服務(wù)。

  James Bach 帶著以下的測試觀點(diǎn)出現(xiàn):

  基本的觀點(diǎn):“如果它存在,我要去測試它”

  正如前面內(nèi)容和我經(jīng)常發(fā)布的文章中,我不同意這個觀點(diǎn)。盡管如此,我完全同意James 在2006年8月7日,他在博客發(fā)布的完整版本中關(guān)于這部分的介紹:

  “如果它存在,我要去測試它(的例外是我有更重要的事情要做)”

  第二句話是可以有很多的理解方式!為什么呢?因?yàn)槲覀兘?jīng)常會有更重要的事情去做,通常是另外的測試工作!不幸的是,重要性往往不是區(qū)分的很明顯。所以與其衡量重要性,我更喜歡提出上面的三個問題,去尋找那些可能不值得浪費(fèi)我的時間去測試的東西。下面八個例子是我討論的內(nèi)容:

  1、不會在產(chǎn)品中出現(xiàn)的組件- 我的團(tuán)隊(duì)中在每次迭代中都有這些內(nèi)容。例如增強(qiáng)功能中的錯誤記錄表或者跟蹤生產(chǎn)活動中的審查報告。在敏捷開發(fā)的團(tuán)隊(duì)中這些被歸入開發(fā)者用戶故事(Developer User Stories)。這些內(nèi)容不會隨便的在產(chǎn)品中出現(xiàn)并且由于其本質(zhì)不會直接影響到用戶。

  2、關(guān)鍵產(chǎn)品問題的補(bǔ)丁不會很糟糕? 下午客戶給我們的技術(shù)支持打電話,由于我們的產(chǎn)品的一個阻塞性質(zhì)的bug導(dǎo)致他們處于錯過一個關(guān)鍵后期限(DeadLine)的邊緣。我們只有一個小時交付修復(fù)的產(chǎn)品。程序員很快的修復(fù)了問題,由于當(dāng)前的產(chǎn)品是無效的,所以對修復(fù)之后進(jìn)一步的產(chǎn)品存在的風(fēng)險來說這是微不足道的。想要當(dāng)英雄嗎?不要讓事情慢下來。快速的讓產(chǎn)品通過測試。如果需要以后再去測試。
  
     3、界面問題修復(fù)要有適度的準(zhǔn)備時間? 我們修復(fù)了一個在屏幕上出現(xiàn)的用戶錯誤消息中的拼寫錯誤。用戶并沒有察覺到拼寫錯誤但是我們無論如何修復(fù)了問題。很快而且簡單。觸發(fā)這個錯誤消息需要30分鐘的準(zhǔn)備時間,值得嗎?

  4、直接了當(dāng)?shù)呐渲酶淖? 去年我們產(chǎn)品開始偶爾出現(xiàn)很大的作業(yè)不能處理的問題。一個程序員嘗試改變通用配置修復(fù)問題。但在QA的環(huán)境中沒有一個簡單的方法去創(chuàng)建一個足夠大的作業(yè)超過這個臨界值,很難去測試。我們在產(chǎn)品中修改了配置然后用戶很高興的為我們做了測試。

  5、技術(shù)性的需要非程序員的測試? 測試部分功能時需要實(shí)施某種行為而在代碼中設(shè)置斷點(diǎn)來復(fù)現(xiàn)競態(tài)條件.有時測試人員與工具和程序員精通產(chǎn)品代碼的知識并不匹配。討論這個測試但是回避它。

  6、非測試人員借用? 如果團(tuán)隊(duì)中一個非測試人員幫忙去做測試工作,或者更重要的,想幫忙測試某一組件,讓他去做吧。跟他分享測試的思路并且跟他要測試報告。如果你覺得滿意,不需要再去測試它了。

  7、沒有復(fù)現(xiàn)步驟- 程序員偶爾會嘗試某些東西。經(jīng)常會出現(xiàn)一些錯誤報告,但是沒有人能對這些錯誤給出確切的重現(xiàn)步驟。我們也許想對修改的區(qū)域做回歸測試,但是我們發(fā)布的時候不會阻止這種明顯的修復(fù),因?yàn)槲覀儾恢浪懿还苡谩?/FONT>

  8、不足的測試數(shù)據(jù)或硬件? 讓我們面對它吧。在我們QA的環(huán)境中,根據(jù)產(chǎn)品中所需要,大部分情況我們沒有足夠多負(fù)載平衡服務(wù)器。當(dāng)一個有效的測試需要的資源在產(chǎn)品使用環(huán)境之外不可用時,我們可能無法對其進(jìn)行測試。

  很多人也許嘗試想像上面這些如果不去測試會導(dǎo)致的問題。我也會做這些。記住,這些事情也許不值得花費(fèi)我們的時間去測試。再次權(quán)衡你所做的事情,如果在不是很清楚的時候,去問問利益相關(guān)者。

  如果你選擇不去測試某些東西,很重要的是,不能被我誤導(dǎo)。這是在我的團(tuán)隊(duì)中使用到方法。在我們進(jìn)行組件審查時,我們的(測試人員)說,“我們將不會去測試這些”。如果有人反對,我們會改變我們的想法并且測試它。如果沒有人反對,我們“未經(jīng)審查即批準(zhǔn)(rubber stamping)”。即表明沒有被測試讓它通過這樣可以讓他進(jìn)入到終產(chǎn)品。

  所以下次你發(fā)現(xiàn)你自己正在著手做的測試,感覺比其他你應(yīng)該做的事情更不重要時,你應(yīng)該需要考慮…不去測試它。逐漸的,你的團(tuán)隊(duì)將會尊重你的決定并受益于更少的瓶頸,以及在你實(shí)際增加的價值的地方增長的覆蓋率。