軟體測試中不需要測試的八件事

李巖發表於2012-03-13

不要測試它

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

● 我們可以立即執行的最好的測試是什麼?

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

● 這是一個Bug嗎?

● 我已經測試完成了嗎?

 

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

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

● 需要由我來測試它嗎?

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

 

test

 

在我看來,我們提出的問題中和以上三個問題類似的還遠遠不夠。可能這是因為我們已經被告知要測試一切東西。甚至我們的一部分人會在其質量團隊中有一個流程,要求某個人把每一個元件都貼上“已測試”的標籤。我們對待測試就像一個常規的工廠程式,我們甚至有時候引以自豪的說…

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

這類想法可能會讓測試人員有一個壞名聲。由於欠缺思考的過程導致它強調了測試的重要性,而不是給一些人提供最有價值資訊的服務。

James Bach 帶著以下的測試觀點出現:

基本的觀點:“如果它存在,我就要去測試它”

正如前面內容和我經常釋出的文章中,我不同意這個觀點。儘管如此,我完全同意James 在2006年8月7日,他在部落格釋出的完整版本中關於這部分的介紹:

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

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

0. 不會在產品中出現的元件- 我的團隊中在每次迭代中都有這些內容。例如增強功能中的錯誤記錄表或者跟蹤生產活動中的審查報告。在敏捷開發的團隊中這些被歸入開發者使用者故事(Developer User Stories)。這些內容不會隨便的在產品中出現並且由於其本質不會直接影響到使用者。

1.  關鍵產品問題的補丁不會很糟糕 – 一天下午客戶給我們的技術支援打電話,由於我們的產品的一個阻塞性質的bug導致他們處於錯過一個關鍵最後期限(DeadLine)的邊緣。我們只有一個小時交付修復的產品。程式設計師很快的修復了問題,由於當前的產品是無效的,所以對修復之後進一步的產品存在的風險來說這是微不足道的。想要當英雄嗎?不要讓事情慢下來。快速的讓產品通過測試。如果需要以後再去測試。

2.  介面問題修復要有適度的準備時間 – 我們修復了一個在螢幕上出現的使用者錯誤訊息中的拼寫錯誤。使用者並沒有察覺到拼寫錯誤但是我們無論如何修復了問題。很快而且簡單。觸發這個錯誤訊息需要30分鐘的準備時間,值得嗎?

3. 直接了當的配置改變 – 去年我們產品開始偶爾出現很大的作業不能處理的問題。一個程式設計師嘗試改變通用配置修復問題。但在QA的環境中沒有一個簡單的方法去建立一個足夠大的作業超過這個臨界值,很難去測試。我們在產品中修改了配置然後使用者很高興的為我們做了測試。

4. 技術性的需要非程式設計師的測試 – 測試部分功能時需要實施某種行為而在程式碼中設定斷點來複現競態條件.有時測試人員與工具和程式設計師精通產品程式碼的知識並不匹配。討論這個測試但是迴避它。

5. 非測試人員借用 – 如果團隊中一個非測試人員幫忙去做測試工作,或者更重要的,想幫忙測試某一元件,讓他去做吧。跟他分享測試的思路並且跟他要測試報告。如果你覺得滿意,不需要再去測試它了。

6.  沒有復現步驟– 程式設計師偶爾會嘗試某些東西。經常會出現一些錯誤報告,但是沒有人能對這些錯誤給出確切的重現步驟。我們也許想對修改的區域做迴歸測試,但是我們釋出的時候不會阻止這種明顯的修復,因為我們不知道它管不管用。

7.  不足的測試資料或硬體 – 讓我們面對它吧。在我們QA的環境中,根據產品中所需要,大部分情況我們沒有足夠多負載平衡伺服器。當一個有效的測試需要的資源在產品使用環境之外不可用時,我們可能無法對其進行測試。

 

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

如果你選擇不去測試某些東西,很重要的是,不能被我誤導。這是在我的團隊中使用到方法。在我們進行元件審查時,我們的(測試人員)說,“我們將不會去測試這些”。如果有人反對,我們會改變我們的想法並且測試它。如果沒有人反對,我們就“未經審查即批准(rubber stamping)”。即表明沒有被測試就讓它通過這樣可以讓他進入到最終產品。

所以下次你發現你自己正在著手做的測試,感覺比其他你應該做的事情更不重要時,你應該需要考慮…不去測試它。逐漸的,你的團隊將會尊重你的決定並受益於更少的瓶頸,以及在你實際增加的價值的地方增長的覆蓋率。

 

原文:Eric Jacobson     編譯:伯樂線上 – 李巖

【如需轉載,請標註並保留原文連結、譯文連結和譯者等資訊,謝謝合作!】

 

相關文章