在測試書籍中有一句這樣的話：軟件測試目的是用最少的人力、物力、財力發現最多的軟件缺陷，提高軟件的質量。爲達到此目的，除想方設法提高測試的效率，同樣對測試過程中出現的各種浪費現象的關注也是不可缺少的，在測試過程中最容易出現以下八大浪費現象。
1.過多的執行
我們都在擔心測試不夠全面，測試覆蓋不全。因爲我們知道過少的測試是犯罪，但同樣過多的測試是浪費。設計測試用例本意是爲了規避測試的隨意性，讓我們測試時既不多測也沒有少測。
很多測試同行都提到在總結測試的時候認爲在測試過程中有些功能可以不需要測試得那麼詳細，有些用例存在的意義很小。將容易的、明顯的模塊、功能進行詳細的測試而複雜的功能沒有得到充分測試，這屬於明顯的資源分佈不均導致的浪費。
更有測試成員跟我說，測試用例寧可多不可少，就算裏面有重複的用例也不要刪除，有了總比沒有好！我絕對被這個觀點雷倒了。同樣被雷倒的還有在編寫測試用例的時候，先寫多在評審時刪除多餘的用例。可是騷年，你在浪費整個項目寶貴的時間呀。
過多的執行偏偏有些時候我們還理所當然，認爲多測是必要的。如果我們這麼認爲，那測試就是沒有長進的，因爲如此我們就不會去優化自己的行爲，測試能力將停滯不前。
2.超出範圍的測試
漏測風險是一直存在的，這對於幾乎所有的測試人員都是噩夢。爲了怕承擔責任就去做超出測試範圍的事情，擴大測試工作量，而不是去分析測試邊界、測試重點。反而在測試工作中理所當然的存在，形成了極大的浪費，而且這也不是一個追求卓越的測試人員應有的態度。
3.過多的測試文檔
在編寫文檔的時候，首先要明白相關文檔的作用，如果只顧編寫而忘記編寫的本意了將導致極大的浪費。文檔最重要的作用是保證信息傳遞的有效性、便捷性，保證文檔在查看過程中信息不失真。如果文檔在辛苦編寫後再無查看，那麼該文檔就失去了存在的意義。大多數IT人員不喜歡的事情就是寫文檔，最不喜歡的事情就是寫完全沒用的文檔，最最不喜歡的事情是文檔不但沒用還要求做得非常工整。
也碰到在編寫測試用例時候要求測試步驟要求寫得非常詳細，讓不懂測試的人也能執行。
也碰到過執行用例的時候，將所有過程、結果截圖以規避測試風險。
對此，我由衷的感慨：你們辛苦了！
4.溝通上的浪費
敏捷中有一個重要準則是：無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。聽到過這樣的真實案例：明明在同一個辦公室，轉個身三兩句話說完了，偏偏用個QQ在聊來聊去。不合理溝通機制（如缺陷管理流程制定不合理），甚至網絡不暢通，也會引發溝通上的浪費。
5.等待
等待是測試現場最容易出現的浪費問題。往往很多場合下都會出現等待的情況：任務的前置條件未達到導致工作無法開展，關鍵任務的阻塞導致相關任務不能正常進行，甚至因爲測試人員權限（權力）不夠無法自主開展工作等情況產生的等待。
等待的情況普通存在，對測試工作的正常進行有直接的影響。等待的累計時間越長，測試的風險也就越大。因此，應該統籌規劃，合理組合各個不同的工序，將等待的時間減少到最低限度。
6.管理上的浪費
管理的目的是使工作處於效能最佳的受控狀態，防止、處理和解決出現的問題。當然很多企業在管理上存在着誤區：爲了管理而管理。如果爲了管理而管理，必然要增加很多人爲的障礙，反而適得其反地導致效率降低。
常見的在管理上的浪費有：開沒有價值的例會，任何分配不合理、不公平，領導者權力過於集中，管理者不能解決衝突和矛盾，工具引用不合理，流程機制不適用都可能造成管理上的浪費。
7.動作浪費
恰當、合理且效能最大的動作有助於提高效率，減輕測試人員的身體疲勞。雖然軟件測試工作是一項腦力勞動，但恰當、合理的動作能縮短測試的時間。
我們知道，電腦鍵盤就是通過研究用戶動作而將26個字母進行了重新排列，以求達到最快的輸入。我剛在學習計算機的時候，老師就要求我們指法正確、盲打，基本功的學習爲提高輸入效率和輸入準確率產生了很大效果。快捷鍵的使用，用例執行順序的優化組合都可以提高測試的效率。
通過對測試行爲進行動作分析，總結出最合理的動作，避免出現無效能動作的浪費現象，從而縮短測試的時間。
8.返工
著名的質量學家菲利浦克勞士比在其經典著作《質量免費》中提到高質量就是第一次將產品做好，如果因爲第一次沒有將產品做好而造成的返工將導致成本的增加，同樣造成浪費。