文章列表

• 報到前我畫了 16 個元件的自動化架構，最後只做了 3 個 — 報到前，我替一個零自動化的團隊畫了一張 16 個元件的 App 測試架構圖。真正落地的只有三塊：Mac mini 接實機、self-hosted GitHub Actions、ReportPortal。這篇講藍圖每一塊原本想解決什麼、為什麼
• 一個人從零扛 App 自動化：從 16 個元件的藍圖，到「先求穩定」 — 公司要導入 App 自動化，沒有前人、沒有框架，只有我一個人。這篇是一年多下來的真實經過：藍圖砍到剩三塊、被 flaky 拖垮進度、跟主管重談期待、發現報表全綠是假的、後期 AI 幫忙也幫倒忙，最後把它交給開發團隊，以及學到的一件事。
• 給不小心就會焦慮的 QA：從自動化轉回手動測試後，我怎麼跟 AI 當夥伴 — 被從自動化調回手動測試那天，我第一個念頭是「我是不是沒價值了」。後來發現讓我焦慮的不是 AI，是一副什麼都想追、什麼都怕來不及的濾鏡。這篇整理我怎麼摘掉它，一次只換一塊積木。
• 第二大腦當 Onboarding 資產：用索引筆記當地圖 — 新人來三個月了，還在問「結帳折扣怎麼算」「這個欄位為什麼要這樣驗」。知識明明都在系統裡，他就是找不到入口，只能一條條問你，你變成人肉索引。這篇講怎麼做一張索引筆記當地圖，讓新人順著入口往下走，不靠老鳥也能自己找到答案。
• 為什麼 QA 需要第二大腦？ — 「那個業務邏輯只有某個資深 QA 知道，他一請假整個版本測試就卡住。」測試知識住在少數幾個人腦袋裡，bus factor 就是 1。這篇講 QA 為什麼要把知識寫出來，以及一個找得到、用得上的知識系統長什麼樣子。
• 把 Case 連到業務規則，讓影響範圍自己浮現 — PM 說「結帳流程的折扣計算邏輯改了一下」，你開始憑記憶圈範圍：折扣、運費、會員等級、稅金，圈了一輪心裡還是不踏實。這篇講怎麼把 case 連到業務規則，改動一發生，影響範圍不用靠回想就自己浮現。
• 可重用知識塊：你的測試零件庫 — 接到新功能、坐下來設計 case，寫到第三條又是那套：登入態、權限邊界、空值、錯誤訊息。每個 QA 心裡都有一本，卻很少有人寫出來共用。這篇講怎麼把反覆用到的測試思路整理成有名字的零件，下次設計 case 直接拿來組裝，不用從零想。
• 從踩過的 Bug 整理出測試啟發，同一類問題不再重來 — 又是時區問題。這季的跨日結算因為 UTC/本地時間搞錯出包，跟去年那次幾乎一樣，只是換了個功能。修完了，retro 寫了，大家點頭。三個月後，同一類 bug 換個地方又來一次。這篇講怎麼把踩過的 bug 整理成下次設計測試用得上的測試啟發。
• 組織：讓活的浮上來、死的下沉 — 測試案例庫越積越厚，幾百條 case 沒人知道哪些還準。想清理又不敢刪，最後變成打開只會更焦慮的知識墳場。卡住的原因是分類方式看不出哪些還算數。這篇講怎麼按「跟現在工作有多近」重新整理，讓現在需要的東西浮上來，過期的安靜下沉。
• 蒐集漏斗：讓知識進來有地方落 — 需求散在 Slack、Figma、Jira 和站會的一句話裡，某個關鍵驗收條件 PM 順口提過，沒人記，上線就出事。知識最常消失在蒐集這一關，原因是當下記錄太麻煩、也沒有固定地方放。這篇講三個原則，讓任何形式的知識進來都有地方落。
• 維護習慣：讓第二大腦長在工作流裡，不再爛回去 — 三個月前你建了一套系統，收件位置、分層、零件庫都有了。前兩週很勤，後來衝刺一來，沒空整理，它又悄悄變成另一個墳場。系統會爛，多半是因為把它當成一次性專案，沒有長進工作流。這篇講怎麼讓第二大腦不靠意志力也能活下來。
• 輸出導向：知識要可行動，計畫與報告由零件組起來 — 又要寫測試計畫了。你打開空白文件，游標閃著。做過十幾次，腦袋裡也有一堆累積的知識，但還是從第一個字開始打。寫完發現跟上次那份八成像，只是又手刻了一遍。知識囤了一整個系統，真正要產出的時候卻沒派上用場。這篇講怎麼讓累積的知識輸出成測試計畫和報
• 從寫自動化到經營知識庫：QA 的時間怎麼變成複利 — 今年三月，我停下手上的自動化開發，轉去支援手動測試、協助正式發版。八月之後，公司不再需要自動化測試，我的崗位也正式換了。
• 釐清異常：把 bug 交對人 — 在把 bug 丟給 RD 前，先做功課——分清前端還後端、排除環境汙染造成的偽 bug、用對事不對人的方式描述。這篇講怎麼把「好像壞了」釐清成「這是哪一層的問題」。
• 逆向思維：從「它能動」到「我要弄壞它」 — 正向測試確認軟體能動，破壞性測試才是高階能力——它要求你從失敗場景倒推、質疑「使用者會乖乖照流程走」的假定。這篇講怎麼把腦袋從「驗證它對」切換到「證明它會壞」。
• 重現是科學方法：控制變數與最小重現 — 重現 bug 就像法醫驗屍——邏輯不嚴密，工程師就找不到病因。這篇用控制變數法、邊界值分析、最小重現步驟，把「我這邊會壞」變成一條工程師能照走的最短路徑。
• 攻擊維度地圖：系統有哪些面可以打 — 破壞性測試不是亂打，是有系統地攻擊每個維度。這篇給你一張維度地圖（結構、功能、資料、平台、操作、時間），再配上瘋狂操作、資源中斷、髒資料、併發競態四種實戰手法。
• 驗證修復與回歸：別只測那一個點 — RD 說「改好了」，你只測原本壞的那個點就放行嗎？這篇講缺陷的最後一哩——缺陷生命週期、漣漪效應、波及範圍評估，讓修好的 bug 不會帶出三個新的。
• 偶發 bug 怎麼抓：重現率、日誌、變數隔離 — 最難搞的不是必現的 bug，是十次出現三次的那種。這篇給你抓偶發 bug 的系統方法：標好重現率、從日誌找蛛絲馬跡、隔離變數，並認得偶發背後最常見的幾個成因。
• 缺陷分級：Severity 不等於 Priority — 很多人把「嚴重度」和「優先級」混為一談，結果跟 RD、PM 雞同鴨講。這篇把兩者拆清楚——Severity 是技術影響、客觀、QA 定；Priority 是業務急迫、主觀、PM 定——再講 P0-P2 怎麼分與 Known Issue 取捨
• 寫一份 RD 一分鐘看懂的缺陷報告 — 一份好報告讓工程師一分鐘看懂、立刻開工；一份壞報告換來十回合反問。這篇講報告的結構與證據邏輯——標題三要素、客觀描述、附對的證據。著重「怎麼組織」，措辭口氣交給溝通系列。
• QA 跟 RD 比例多少才合理？一個 QA 搭幾個 RD 的判斷依據 — QA 跟 RD 的比例多少才合理？業界調查從 1:4 到 1:12 都有，沒有標準答案。整理決定配比的五個因素、我們 App 團隊從 1:3 到 2:8 的配比演變，以及自動化成熟度怎麼改變這個比例。
• 怎麼認得「這是 bug」：一致性判準 — 破壞之後，你得認得出異常。「我覺得怪怪的」不夠專業——這篇把它變成可說明的判準：產品該與它的歷史、可比產品、使用者期待、規格與合理性一致，不一致的地方就是 bug 的線索。
• 怎麼改善公司品質 — 工具換了一輪又一輪，測試框架從這個換到那個，品質還是一樣爛。
• 用一個指令整合三個工具：我的每日工作流實作 — 每天早上最浪費的那段時間，不是開會，是切頁籤。Todoist 看今天要做什麼，Slack 看 #ops 有沒有緊急事，Linear 確認有沒有新 issue 分進來。三個工具，三次切換，還沒正式開工，注意力已經碎了一輪。
• 為什麼你的 unit test 覆蓋率 100% 但 QA 還是找到 bug — unit test 覆蓋率 100%，QA 還是找得到 bug。unit test 驗證的是單一模組的邏輯，模組接在一起的行為、真實資料、環境差異它天生測不到。從這裡重新理解測試金字塔的意義。
• QA 從零建立：新創公司沒有 QA 流程，第一件事做什麼 — 新創公司招了第一個 QA，之前都是 RD 自己測。從零建立 QA 流程的常見錯誤起點、正確的順序，以及三個月內能建好的品質基礎，附我們 App 團隊的實際情況。
• 測 IAP 和第三方整合：Apple、Google 的沙盒環境有多難搞 — IAP 測試最難搞的是環境：sandbox 帳號隔幾週就失效，訂閱狀態不同步，退款流程難重現。整理我的 IAP 測試流程、Google Play 和 App Store 沙盒的差異，以及第三方整合的測試原則。
• AI 系統上線前，你測過這些嗎？Taco Bell 和 McDonald's 的慘痛教訓 — Taco Bell 的 AI 點餐系統被一張 18,000 杯水的訂單搞崩，McDonald's 的 AI 招聘系統密碼是 123456。從兩起事故整理 AI 系統的測試盲點，以及 QA 上線前該問的問題。
• AI 測試案例生成實戰（2026）：AI 給我 50 個案例，有 20 個在測不存在的功能 — Stack Overflow 2025 年的開發者調查裡，66% 的人說 AI 最讓人困擾的地方是「答案幾乎對，但就是差一點」。測試案例是這種差一點最難被發現的地方：格式整齊、分類清楚、邊界值也有列，看起來沒什麼好挑的，一跑才知道。
• 測試資料管理：為什麼你的測試環境總是一團亂 — 測試帳號昨天還能用、今天就壞，staging 資料越測越亂。整理測試資料亂掉的幾種形式，以及我怎麼用 seed script 和定期清理，把測試環境管回可控狀態。
• Push Notification 測試：你以為推了，用戶不一定收到 — 「推播已送出」和「用戶收到推播」是兩件完全不同的事。從後端觸發到用戶看到橫幅，中間至少經過五個可能失效的環節——而你的測試環境幾乎模擬不了任何一個。這篇文章聊的就是這個落差。
• QA 工程師的第一條 GitHub Actions Pipeline — 測試什麼時候跑，取決於我有沒有空、有沒有被通知。用 QA 的語言介紹 GitHub Actions 的四個核心概念，帶你寫第一條 workflow：PR 一開就自動跑測試，跑完怎麼看結果。
• Proxyman 教學：QA 的 iOS／Android HTTPS 攔截設定與五個實戰場景 — Proxyman 教學：iOS 模擬器、真機與 Android 的 HTTPS 攔截設定（含 network_security_config），加上 QA 最常用的五個場景：檢查 request、模擬錯誤回應、Map Local、追 fla
• 為什麼 RD 把你當路障？QA 如何從被防禦變成被信任 — 回報 bug 時，RD 第一句是「一定要修嗎？」。QA 被當成路障，根源常在 KPI 衝突。分享五件讓 RD 開始信任 QA 的具體做法，以及信任建立後，合作會變成什麼樣子。
• QA 怎麼量化自己的價值，給主管看的那種數字 — 「QA 這季做了什麼？」回答測了幾個功能、開了幾張 bug，主管其實聽不出價值。整理哪些 QA 指標無效、哪些數字真的能說明品質貢獻，以及這些數字要怎麼收集。
• 三個月後我的自動化測試變成了維護地獄 — 我把 120 個 App 測試案例全部自動化，三個月後 CI 每次有 20 到 30 個紅燈，大多是 flaky test。整理什麼適合自動化、什麼不適合、模擬器和真機怎麼分工，以及 flaky rate 從 25% 降到 5% 的做法。
• 為什麼加快 release 頻率之後，bug 反而變多了 — release 從一個月一次改成兩週一次，bug 反而變多。根本原因不是 QA 測不完，是讓速度可持續的流程沒有跟著調整。從 DORA 研究和實際經驗，整理加快發布後維持品質的做法。
• 例行維護出大事：Optus 升級防火牆，救護車叫不到 13 小時 — Optus 一次例行防火牆升級，讓澳洲緊急電話 000 斷線 13 小時。從這起事故看例行維護為什麼最危險、三種讓維護變成事故的模式，以及 QA 在 Change Management 能做的檢查。
• 我憑什麼相信綠燈 — 我改的那一行，是讓文章目錄誤收 h4 標題——一個真實會壞掉的 bug。但我寫的每一個測試都說「沒事」。那一刻卡住我的不是技術，是一個更難的問題：我憑什麼相信「綠燈」？
• 動手抓出你的綠燈謊言 — 我把自己的程式改錯，七個測試卻全綠。如果你也想知道自己的測試是不是正在說謊，這篇教你動手把它抓出來。
• Cache 測試：快取讓 bug 更難找，也讓 bug 更難修 — App 顯示購買成功，回到商店頁卻還是未解鎖，RD 說「可能是 cache 問題」。整理快取讓測試變複雜的幾種方式、cache 相關的測試策略，以及快取失效時要測的邊界情境。
• QA Brain：讓 AI 真的懂你的產品，而不是亂猜 — AI 生成的測試案例格式整齊，卻沒考慮產品的歷史 bug 和隱含規則。QA Brain 是我建的產品知識庫，用五層架構和 workflow skills 餵給 AI，讓它產出真正貼合產品的測試案例，不再亂猜。
• 測試左移右移不是新術語，是你測試的時間點出了問題 — 功能做完才交給 QA，架構和邊界處理早就定案，能做的只剩驗證。測試左移、右移在講的是測試時間點：左移是什麼、右移是什麼、兩邊怎麼一起做，以及我目前的實際狀況。
• 那一成紅燈，差點讓我放掉一隻登入 bug — 那天整批 Appium 測試開始紅，git log 卻乾乾淨淨——沒人改過測試，也沒人改過功能。它就是，自己開始壞了。
• Retro 說了沒用？問題不是你說錯了，是你說法讓問題變得無法行動 — Retro 上提的問題，下個 sprint 照樣發生。問題常常不在內容，在說法讓人無法行動。整理四種讓問題無法行動的說法、怎麼改寫成可執行的格式，以及 QA 在 Retro 該扮演的角色。
• App 測試為什麼比網頁測試難這麼多？ — 從網頁測試轉向 App 測試，很多 QA 都有一樣的感受：「明明是同一個功能，為什麼行動端要花兩倍時間？」
• Appium 搭配 pytest 完整實務：從 fixture 設計到 CI 執行 — Appium 測試最難的不是讓第一個測試跑起來，而是三個月後維護一個 50 個測試案例的專案時，還能快速加測試、快速找問題、CI 上跑起來不是每次都賭運氣。
• CI 測試跑太慢？平行化策略與最佳化 — CI 跑太慢的問題通常是這樣開始的：一開始 10 分鐘，大家覺得還好。半年後功能多了，變成 25 分鐘。再半年，40 分鐘。開發者開始不等 CI 結果，直接 merge。
• GitHub Actions vs Jenkins：CI 工具怎麼選 — 這個問題我在兩個地方看到最多：剛導入 CI/CD 的小團隊在問，和 Jenkins 用了五年開始覺得維護成本太高的大團隊也在問。
• 測試的問題每間公司都有，但為什麼每間公司都沒解決 — 每次看都覺得說得對。每次看完還是覺得沒有用。
• AI 時代，測試的 Domain Knowledge 比過去更重要 — AI 幾秒鐘就能產出一批測試案例，但哪些值得跑、哪些漏了關鍵情境，還是要靠人判斷。AI 沒有你的 bug history，也會製造假安全感。這是為什麼 AI 時代，測試的 domain knowledge 反而更重要。
• Playwright 進階：讓測試從能跑，變成團隊敢信任的東西 — 一個測試套件能跑，和一個測試套件讓人放心，是兩件完全不同的事。
• QA 怎麼影響架構決策？從可測試性談起 — 一個難以測試的系統，幾乎必然是難以維護的系統。
• 測試策略怎麼跟 PM 對齊？從需求會議就開始的 QA 工作 — 大多數 QA 的工作從「開發完成，請測試」才開始。這是一個代價很高的習慣。
• 什麼情況下不該自動化？停下來比衝快更重要 — 自動化是 QA 的標配技能，卻也是最常被誤用的工具。
• 同一個地方一直出 bug？QA 的六步問題分析法 — 同一個功能，修了又壞，壞了又修。每個 sprint 都有人說「這個上次已經修過了」，然後 QA 又重新開一張 bug ticket。
• 拿到票單的時候，QA 已經輸了 — 每次 sprint planning 結束，QA 拿到一份 User Story 清單，然後開始想：要怎麼測？從哪裡開始？什麼是完成的定義？
• CI 過了不代表沒問題：DevOps 時代的測試策略全貌 — 很多團隊導入 CI/CD 之後，會出現一個誤解：
• App 工程師的 Unit Test 實戰課：你的測試真的在測東西嗎？ — unit test 全過，CI 綠燈，release 出去，用戶回報 bug。
• 不需要 Manager 頭銜，QA 也能成為領導者 — 很多 QA 工程師在職涯的某個時間點，會面對同一個問題：
• 自動化測試策略：從冰淇淋到金字塔 — 我第一份工作的測試套件，大概 95% 都是 UI E2E 測試。
• Self-Healing Appium 框架：讓定位器斷掉也能自動修復 — 我第一次看到「self-healing test framework」這個詞，覺得有點誇大其詞。
• 《Software Engineering at Google》讀完，我才知道新創少了什麼 — 讀完《Software Engineering at Google》，我對照新創團隊的日常：Code Review 形同虛設、測試永遠之後再補、出事只找人。整理書中 Code Review、Testing Grouplet、Blameles
• BDD 不只是工具，是溝通框架：pytest-bdd 完整筆記 — PM 說「使用者登入後應該看到儀表板」，開發理解成「登入成功轉跳到 `/dashboard`」，QA 測試時發現「登入後出現歡迎彈窗，再跳轉儀表板」——三個人各自理解了同一個需求，但沒有一個版本完全對齊。
• 用 GitHub Actions 跑測試：TAU 課程完整筆記 — QA 常遇到一個尷尬的狀況：測試寫好了，但只能手動跑。
• pytest 從零開始：TAU 課程完整筆記 — 我用 pytest 已經一段時間了，但一直是「會用，但不懂為什麼這樣設計」的狀態。
• QA 是瓶頸，還是觸媒？全團隊持續測試的真正意義 — 這句話我聽過很多次，也說過很多次。有時候是抱怨，有時候是辯護。但課程講師 Lisi Hocke 的親身故事讓我第一次真的停下來想：如果 QA 一直是個關卡，問題是在人還是在流程？
• QA 也要懂效能測試：TAU 課程完整筆記 — QA 常遇到這個問題：功能測試都通過了，上線後使用者說「網站好慢」。
• 測試自動化的可觀測性：TAU 課程完整筆記 — 你有沒有這種感覺：CI 跑完了，測試結果出來了，但你卻不知道「今天這一跑」和「昨天那一跑」有什麼差別？
• 從零打造測試自動化：TAU 課程完整筆記 — 學了幾年自動化，一直是「需要什麼就學什麼」的被動模式。直到最近在 Test Automation University 上完 Angie Jones 的 *Setting a Foundation for Successful Test A
• 我用技術語言跟老闆報告自動化測試，他聽了三分鐘就去開別的會 — 跟主管報告自動化測試，講架構、講 locator 策略，對方三分鐘就失去興趣。我後來學會把自動化翻成 release 速度、風險、成本這些業務語言，主管才聽得進去。
• Leader 說要改善流程，但我不知道怎麼配合 — 某個 sprint 開始前，Leader 在 Slack 發了一則訊息：「這個 sprint 我們要試行新的 test plan review 流程，每個功能測試前要先提交 test plan 給我看。」
• 用 k6 打爆服務之後，我才學會怎麼做效能測試 — 第一次用 k6 做壓測，我直接開 1000 個 VU，把導航服務打掛。從這次事故整理效能測試的類型、實際跑的 k6 腳本、怎麼判斷服務是被你打掛的，以及幾個踩過才懂的細節。
• 那次 CI 全紅，我才搞懂 Appium 到底在做什麼 — 本機跑得過，CI 卻全紅，錯誤是 NoSuchElementException。追到最後是 XPath 寫死 index。藉這次經驗講清楚 Appium 的架構、driver 和裝置怎麼溝通，以及比較穩的 locator 策略。
• ISTQB 七大原則，我工作三年才真正懂的那幾條 — 考 ISTQB 那年，我把七大原則背得滾瓜爛熟，選擇題全對。但真正讓我在某次上線前夜冒冷汗、回頭發現「啊，這就是那條原則在講的事」，是三年後。
• QA 的第二大腦：用 PARA 把散落的測試知識收成系統 — 踩過的 bug、查過的 log、測試心得散在十個地方，需要時找不到。用 PARA 按可行動性分類，把 QA 的測試知識收成一套第二大腦系統，附明天就能開始的三個動作。
• 一個 QA 親手打一次 OWASP Juice Shop，學到的六種測試技能 — OWASP Juice Shop 教學：QA 親手打一次這個故意寫爛的資安靶場，從安裝跑起來，到 XSS、SQL Injection、Broken Authentication 等六種漏洞，各自對應一個能放進日常測試 checklist 的
• 那張被關掉的 bug ticket，讓我搞懂什麼叫做真正的 bug report — 我回報的 bug 被標成 Cannot Reproduce 關掉。回頭看才發現問題出在 bug report 本身：重現步驟、環境、預期與實際結果少了哪些，RD 就修不了。附我現在寫 bug report 的格式。