ISTQB 七大原則，我工作三年才真正懂的那幾條

原則本身誰都查得到。難的是——它什麼時候會在你身上發生，而你認不認得出來。這篇不重述定義，只講每一條原則，後來在我身上長成了什麼樣子。 七大原則，與它們真正咬人的時刻 先把七條擺出來，一句話定義，再說我踩到的版本。 原則 教科書說 我學到的版本 1. 測試顯示缺陷存在 測試證明有錯，不能證明沒錯 「我測過了」不等於「沒問題」 2. 窮盡測試不可能 測所有組合不切實際 所以你選什麼不測，才是真本事 3. 盡早測試 越早測越省成本 越早測，省的是別人的時間 4. 缺陷具叢聚性 bug 集中在少數模組 上次爆的地方，這次大概也爆 5. 殺蟲劑悖論 重複同案例抓不到新 bug 你的回歸套件正在過期 6. 測試視情境而定 不同領域嚴謹度不同 沒有「最佳實踐」，只有「這裡適合什麼」 7. 沒有錯誤不代表有用 找不到 bug 也可能是爛產品 做對了規格，不等於做對了東西 下面挑幾條真正在我工作裡留下疤的。 第 2 條：窮盡測試不可能 —— 重點不是「測不完」，是「你敢不敢決定不測」 剛入行時我把這條讀成一句洩氣話：反正測不完，盡力就好。完全錯。 這條真正的意思是：既然測不完， 那你怎麼選 就是專業所在。你願意明確說出「登入流程我測到死，後台某個三年沒人動的報表頁我這版不測」——並為這個取捨負責——那才是測試設計。風險基礎測試整套方法，就是建在這條原則上（我寫過一篇講怎麼用風險決定測試優先序）。 含糊地「盡力測」不是謙虛，是逃避決策。 第 3 條：盡早測試 —— 省的是別人的時間，所以你要主動往前擠 Capers Jones 的經典統計：缺陷修復成本每往後一個開發階段，大約增加 10 倍。需求階段抓到改一行字，上線後抓到可能是一次 hotfix 加一場事後檢討。 但這條的陷阱是，「盡早」聽起來像在說測試執行要提前——不是。是 測試思維 要提前。需求還在 Figma、PRD 還在吵的時候，QA 就該進去問「這個 empty state 怎麼處理」「網路斷了會怎樣」。那時候提出來，改的是一句規格；等做完再提，改的是別人三天的程式碼（這也是我對 shift left 的一些保留——左移不是把活往前塞，是把問題往前問）。 第 4 條 + 第 5 條：叢聚性與殺蟲劑悖論 —— 一對矛盾的雙胞胎 這兩條放一起看才有意思，因為它們表面上打架。 叢聚性 說：bug 集中在少數模組，上次爆的地方這次大概也爆，所以火力要集中在那。Pareto 在這裡很真實——大約 80% 的缺陷來自 20% 的模組。 殺蟲劑悖論 說：同一組案例跑久了就失效，因為那些 bug 早被修光了，蟲對你的藥產生抗性。 所以呢？火力集中在熱點（第 4 條），但用同一套案例反覆打那個熱點，又會鈍化（第 5 條）。解法是： 盯著對的模組，但不斷換新的攻擊角度 。同一個高風險模組，這版用邊界值打、下版用異常流打、再下版用併發打。熱點不變，彈藥要換。 我自己的回歸套件就吃過這個虧——跑了一年全綠，漂亮得可疑。後來換了個新人用沒看過的路徑點一遍，當場三個 bug。不是程式變爛，是我的測試對它免疫了。 第 7 條：沒有錯誤不代表有用 —— 最容易背、最難做到的一條 ⚠️ 注意： 這是七條裡唯一一條，會讓「測得很乾淨」變成一種危險的自我感覺良好。 你可以把所有 bug 都修光、所有案例都綠燈，然後交出一個沒人想用的東西。因為你驗的是「規格有沒有被正確實作」，不是「這規格本身對不對」。 我看過一個功能，QA 報告漂亮無比，零缺陷上線，兩週後使用率趨近於零——因為它解決的是一個使用者根本沒有的問題。測試全綠，產品全錯。這條原則在提醒的是：QA 的終點不是「符合規格」，是「對使用者有用」。這也是為什麼我一直主張 QA 要懂業務、要參與規格討論，而不只是接收需求然後驗收。 那 F.I.R.S.T. 呢？那是給另一群人的原則 很多人把 ISTQB 七原則和 F.I.R.S.T. 混在一起背，其實它們服務的是不同的人。 七大原則是 測試這件事 的世界觀，給所有做測試的人。F.I.R.S.T. 是 單元測試怎麼寫 的工程準則，主要給寫 code 的人（含寫測試 code 的 SDET）： F ast（快）：跑得快，開發者才願意頻繁跑。 I ndependent（獨立）：案例彼此不相依，任意順序、單獨都能跑。 R epeatable（可重複）：任何環境跑結果一致——不依賴特定時間、特定機器、外部服務。 S elf Validating（自我驗證）：明確輸出 pass / fail，不用人去翻 log 判讀。 T imely（及時）：測試與正式碼同時或緊接著寫（TDD 的核心）。 為什麼 QA 也該懂這套？因為當你開始 review 開發寫的單元測試，F.I.R.S.T. 就是你的檢查清單。一個依賴執行順序才會綠、跑兩次結果不同、或要人去看 console 才知道有沒有過的「測試」，違反的正是 I、R、S——它不是測試，是會說謊的綠燈。 我寫過一篇講單元測試 100% 覆蓋率，QA 還是抓到一堆 bug 的事。很多時候不是覆蓋率假，是那些測試根本不符合 F.I.R.S.T.，覆蓋了等於沒覆蓋。 背過，和懂了，差三年 這些原則的價值不在背得出來，在於某天現場出事時，你腦中有一個名字可以套上去——「啊，這是殺蟲劑悖論」「這是第 7 條」。有了名字，你才講得清楚問題、說服得了團隊、也才知道下一步往哪走。 如果你正準備 ISTQB，背是必要的。但別停在背。挑一條，去你手上的專案裡找它正在發生的證據。找到那一刻，你會比考一百分還懂它。 參考資料 ISTQB Certified Tester Foundation Level (CTFL) Syllabus — 七大原則的官方定義與情境出處 ASTQB — Seven Principles of Software Testing — 美國分會對七原則的整理與範例 Capers Jones, "Applied Software Measurement" — 缺陷修復成本隨階段遞增的數據來源 Boris Beizer, "Software Testing Techniques" — 殺蟲劑悖論（pesticide paradox）一詞的原始出處 Robert C. Martin (Uncle Bob) — The FIRST principles — F.I.R.S.T. 單元測試原則的常見整理