為什麼我去考了這張證照？

一直以來都有想要補足軟體測試領域知識的想法。

在成為一個 QA Engineer 前已從網路文章與書本上見識到了軟體測試這門領域的豐富。不過礙於當時見識尚淺，那些前人整理出的理論與實踐，如同學校所教授、無法體會的知識一樣，自然是被大腦過濾與遺忘。

在週期性地重複執行那些 "經驗導向" 的工作行為一年半後，心裡浮現諸多疑問：

1. 這難道就是全部了？
2. 不對吧？ "印象" 中軟體測試或是 Quality Assurance 不僅止於此才對。

後來我發現，是環境限制。 在缺乏文化與標準的體制下想建立系統化的品質思維簡直難如登天。

「QA 是什麼 ?」 這個問題，在公司裡問十個人會得到十個答案。

PM、RD、UI/UX、Sales、Marketing，甚至 QA team 內部每個人都有不同的詮釋。

我想了想，果然還是需要有個方法更系統性地學習軟體品質 & 測試思維。在一番摸索之下，最終找上了最多人推薦的 ISTQB CTFL。

所以 ISTQB CTFL 到底在學什麼？

CTFL 是由 ISTQB 所推出的基礎級認證。

它不教你如何按按鈕測試。 它也不教你如何使用特定工具來測試軟體。

它教的是與測試相關的理論與實踐。 先釐清所有基礎觀念後，再向外延伸討論實務活動與相關技巧。

就像醫學院不會一上來就教你如何開刀，而是先從理論開始，爾後才教你判斷何時該開、何時不該開。

以下是讀完後我覺得三個值得與一般人分享的觀念轉變：

1.「測完沒 bug」不代表產品沒問題

測試從來都不是為了證明產品沒問題，而是為了找到問題。

很多團隊以為「測試全部通過 = 產品沒問題」。但通過測試只是符合了規格，不代表不存在任何的缺陷。這就像健康檢查報告沒有紅字，仍不能保證一個人「完全沒病」。

另外，通過所有測試也不代表產品就一定會成功。 任何產品或服務，「符合規格」和「滿足需求」是兩回事。

舉個例子：「七分熟、去洋蔥」的牛排，廚師完全照做了（符合規格），但送上來的肉質卻像橡皮筋一樣難以下嚥。這道菜在技術上通過了你的「規格檢查」，但它並沒有「滿足」客戶對享受美食的需求。

大部分人以為 QA 只在做前者，但其實後者才是更核心的價值。

2. 測試比想像中的簡單？

很多人以為測試很簡單，只要動動手指點一點、或是操作一下找找 bug 即可。 但其實測試需要策略性地選擇，並設計出能夠檢驗品質的方法。

我們都知道時間與資源是有限的，所以必須要進行一些取捨。 測試作為檢驗品質的一種方式，窮盡測試是不可能的。

既然不可能全測，選擇有效的策略至關重要。

儘早測試更省成本。 測試不是開發完成後才開始的最後一關，而是貫穿整個開發流程。

如果蓋房子到最後才發現地基有問題，拆掉重來的成本遠大於一開始就做好地基檢測。軟體開發也一樣：在需求階段就發現錯誤，修正成本可能只是幾小時的討論; 但如果到上線後才發現，代價可能是使用者流失和商譽損害。

所以要聰明地選擇什麼時候測、測什麼、以及如何測。 測試沒有一個統一的標準或是萬能解。 不同產品、不同階段，測試的重點和方式各不相同。

3. 沒有一勞永逸的測試策略

就像行銷策略不能一招打天下——去年有效的廣告素材今年可能完全失靈。

測試也一樣，如果永遠用同一批測試案例來進行測試，能發現的 Bug 將會越來越少，而逐漸變得沒有作用。

既然要持續更新策略，那該把力氣優先花在哪裡呢？

實務上，大部分的 bug 往往集中在少數的幾個地方。

做過業務的人都知道，80% 的營收往往來自 20% 的客戶。頂尖的業務不會把時間平均撒在所有客戶身上，而是集中經營那些關鍵帳戶。

知道重災區在哪，才能把資源用在刀口上。

好的 QA 會根據產品演進、風險變化，持續調整測試策略。

考完之後，真正的收穫是什麼？

我覺得這次學習 & 考取認證的最大收穫倒不是這張證照本身，而是能夠將工作上的經驗與實務理論做一個連結對照。

親身投入軟體測試領域讓我得以體悟那些前人留下的 "經驗" 之談，其實背後都有一套基於實踐的理論原則。

至此，我有一套能跟不同角色對話的共同框架，而並非如先前一樣問十個人有十個不同答案。

接下來， 我會進一步探索 CT-genAI 認證，看看生成式 AI 可以如何協助軟體測試的進行。除此之外，也期待帶著這套共同語言，在更重視品質文化的環境中持續實踐。