2、評估測試代價

　　● 測試的消耗有多大？我們能承受的測試代價是多大？

　　● 我們能否從測試覆蓋中消除不必要的冗余？

　　● 是什么讓測試執行困難（代價高）？

　　● 產品的可測性能否再提高？

　　● 是否有工具或技術可以使測試過程更加高效？

　　● 早點測試好還是遲點測試好?哪種情況下測試的整體成本低一些？

　　3、檢查測試對決策的作用

　　● 測試過程是否清楚管理者、開發人員或其它客戶需要做的決定？

　　● 測試過程是否關注潛在產品和項目風險？

　　● 測試過程是否依賴變更控制過程和項目管理？

　　● 測試報告是否及時遞交？

　　● 測試報告是否用易于理解的方式溝通？

　　● 測試過程和測試結果一樣被傳達嗎？我們是否報告評估的基礎以及融入我們的信心在里面？

　　● 測試過程是否對技術支持、發行、市場或其它需要使用質量評估的任何業務過程提供服務？

　　4、是否及時

　　以上三方面都是時間驅動的。所以帶來了問題：我們永遠也沒有足夠的時間去做每一件事，所以我們要做的每一件事都是與時間賽跑。

　　整合分析

　　1、我們的測試有多好？

　　● 綜合前面的幾個問題，考慮我們現在的測試過程中是否存在緊迫的問題？

　　● 我們的測試流程是否充分，是否能在產品質量未能達到預期目標時對項目管理提出預警？

　　● 是否存在某些潛在類型的問題是不可忍受的，如果有，我們是否有有信心我們的測試流程能發現定位這些問題？

　　2、是否值得改進？

　　● 我們能用什么策略改進測試？

　　● 我們有能力應用這些測試策略嗎？我們知道怎樣應用嗎？

　　● 改進測試會消耗多大？會有多麻煩？是否是利用資源的佳方式？

　　● 能否暫時不改進？能否在一個可接受的時間范圍內達到改進？

　　● 改進是否會造成反效果，引入新的bug，對士氣造成影響？

　　● 改進會帶來明顯的不同嗎？

　　測試經理不愿意面對“毫無遺漏的測試是不可能的”這一事實的話，他會選擇一個不可能完成的測試。

　　Good Enough Testing 的目的是幫助軟件測試工程師擺脫測試的條條框框、主觀性、被動的局面，把結構化的、合理的方法應用到復雜的、多維的問題集合中去。