做為一名測試人員，我們也許會問我們自己很多問題：
● 我們可以立即執行的最好的測試是什麼？
● 我将要使用的測試方法是什麼？
● 我已經測試完成了嗎？
但是我們之中會有多少人提出以下的這些問題呢？
● 這個元件需要一直被測試到嗎？
● 需要由我來測試它嗎？
在我看來，我們提出的問題中和以上三個問題類似的還遠遠不夠。可能這是因為我們已經被告知要測試一切東西。甚至我們的一部分人會在其品質團隊中有一個流 程，要求某個人把每一個元件都貼上“已測試”的标簽。我們對待測試就像一個正常的工廠程式，我們甚至有時候引以自豪的說…
“我是測試工程師。是以，所有的東西都需要被測試…由我來做…即使非測試人員已經測試過了…即使我已經知道它将會通過測試…即使需要一個程式員告訴我怎麼去測試…我必須測試它，沒有例外！”
這類想法可能會讓測試人員有一個壞名聲。由于欠缺思考的過程導緻它強調了測試的重要性，而不是給一些人提供最有價值資訊的服務。
james bach 帶着以下的測試觀點出現：
基本的觀點：“如果它存在，我就要去測試它”
“如果它存在，我就要去測試它（唯一的例外是我有更重要的事情要做）”
第二句話是可以有很多的了解方式！為什麼呢？因為我們經常會有更重要的事情去做，通常是另外的測試工作！不幸的是，重要性往往不是區分的很明顯。是以與 其衡量重要性，我更喜歡提出上面的三個問題，去尋找那些可能不值得浪費我的時間去測試的東西。下面八個例子是我讨論的内容：
2、關鍵産品問題的更新檔不會很糟糕– 一天下午客戶給我們的技術支援打電話，由于我們的産品的一個阻塞性質的bug導緻他們處于錯過一個關鍵最後期限（deadline）的邊緣。我們隻有一個 小時傳遞修複的産品。程式員很快的修複了問題，由于目前的産品是無效的，是以對修複之後進一步的産品存在的風險來說這是微不足道的。想要當英雄嗎？不要讓 事情慢下來。快速的讓産品通過測試。如果需要以後再去測試。
3、界面問題修複要有适度的準備時間– 我們修複了一個在螢幕上出現的使用者錯誤消息中的拼寫錯誤。使用者并沒有察覺到拼寫錯誤但是我們無論如何修複了問題。很快而且簡單。觸發這個錯誤消息需要30分鐘的準備時間，值得嗎？
4、直接了當的配置改變– 去年我們産品開始偶爾出現很大的作業不能處理的問題。一個程式員嘗試改變通用配置修複問題。但在qa的環境中沒有一個簡單的方法去建立一個足夠大的作業超過這個臨界值，很難去測試。我們在産品中修改了配置然後使用者很高興的為我們做了測試。
5、技術性的需要非程式員的測試– 測試部分功能時需要實施某種行為而在代碼中設定斷點來複現競态條件.有時測試人員與工具和程式員精通産品代碼的知識并不比對。讨論這個測試但是回避它。
6、非測試人員借用– 如果團隊中一個非測試人員幫忙去做測試工作，或者更重要的，想幫忙測試某一元件，讓他去做吧。跟他分享測試的思路并且跟他要測試報告。如果你覺得滿意，不需要再去測試它了。
7、沒有複現步驟- 程式員偶爾會嘗試某些東西。經常會出現一些錯誤報告，但是沒有人能對這些錯誤給出确切的重制步驟。我們也許想對修改的區域做回歸測試，但是我們釋出的時候不會阻止這種明顯的修複，因為我們不知道它管不管用。
8、不足的測試資料或硬體– 讓我們面對它吧。在我們qa的環境中，根據産品中所需要，大部分情況我們沒有足夠多負載平衡伺服器。當一個有效的測試需要的資源在産品使用環境之外不可用時，我們可能無法對其進行測試。
很多人也許嘗試想像上面這些如果不去測試會導緻的問題。我也會做這些。記住，這些事情也許不值得花費我們的時間去測試。再次權衡你所做的事情，如果在不是很清楚的時候，去問問利益相關者。
如果你選擇不去測試某些東西，很重要的是，不能被我誤導。這是在我的團隊中使用到方法。在我們進行元件審查時，我們 的（測試人員）說，“我們将不會去測試這些”。如果有人反對，我們會改變我們的想法并且測試它。如果沒有人反對，我們就“未經審查即準許（rubber stamping）”。即表明沒有被測試就讓它通過這樣可以讓他進入到最終産品。
是以下次你發現你自己正在着手做的測試，感覺比其他你應該做的事情更不重要時，你應該需要考慮…不去測試它。逐漸的，你的團隊将會尊重你的決定并受益于更少的瓶頸，以及在你實際增加的價值的地方增長的覆寫率。
本文出自seven的測試人生公衆号最新内容請見作者的github頁：http://qaseven.github.io/