【 Lessons Learned in Software Testing 】#5 Find important bugs fast.
請優先找出重要的Bug
找出重要 important 的 Bugs (與詞 insignificant 意思相反) 、並且要迅速地找到 …
那如果要達到上述所說的，測試人員有麼要注意、或參考的做法？
👉 先測試 變更的部分 (things that are changed) 再測試與之前相同部分 (things that are the same)
修正 (Fixes) 與 更新 (Updates) 都意味著新的風險。
👉 先測試 核心功能 (core functions) 再測試次要、輔助的功能 (contributing functions)
測試產品關鍵、常用的功能，就等於知道產品是什麼、完成那些事情。
👉 先測試 能力(capability) 再測試 可靠性(reliability)
先測試每個功能是否完全地能夠使用，再深入檢驗任何一個功能在不同的條件下，是否都能正常運作。
👉 先測試 常見情況(common situations) 再測試 少見情況(esoteric situations)
使用常用數據、資料、使用場景去執行測試。
👉 先測試 常見威脅(common threats) 再測試 少見威脅(esoteric threats)
用最有可能出現的壓力與錯誤情況進行測試
👉 先測試 影響程度較大的問題(high-impact problems) 再測試 影響程度較小的問題 (low-impact problems)
先測 high-impact problems 部分只要一出錯，產品就會無法正常運作
👉 先測試 最需要的部分(most wanted areas) 再測試 非(必要)需求部分 (areas not requested)
先測試對團隊其他人有重要意義的任何問題。
如果測試人員對產品本身、與產品有互動的軟硬體，以及是誰使用這產品更加了解，越有可能更快地找出重要問題。
後記
此篇章時以「重要 (Important)」的程度去探討，什麼部分先測試 … ，但實務上總是有另一個 force 影響著事情的排序，那就是 「緊急 (Urgent)」的程度， Important X Ugrent 就劃分出四個象限，也就是艾森豪矩陣 (Eisenhower Matrix) 所要帶給我們的排定工作項目的優先順序和管理工作的概念…細節請參考以下連結:
