QA 作品集實戰 — AI 時代用 4 種 side project 證明你不會被取代

面試 QA 十年，我看過的履歷有八成寫「熟悉 Playwright / Selenium」，但附上 GitHub 連結的不到一成 — 而那一成拿到面試的機率完全是另一個量級。AI 時代這件事更極端：test case 誰都能用 AI 生出來，所以「宣稱會」的價值歸零，「證明做過」的價值翻倍。這篇講 QA 作品集到底放什麼、做到什麼程度、面試怎麼講。

為什麼 2026 年的 QA 特別需要作品集

  • 履歷關鍵字已經死了：ATS 時代大家都會堆 keyword，AI 時代連 STAR 故事都能生成，面試官只信可驗證的東西
  • QA 的工作成果天生難展示：你測過的產品不能公開、bug report 是公司資產 — side project 是唯一合法的展示窗口
  • 轉職者的破局點：沒有 QA 職稱的人，一個扎實的測試專案就是你的「工作經驗」

一句話：作品集不是加分項，是把「AI 取代焦慮」變成「AI 加值敘事」的實體證據。

4 種作品類型：從最容易到最有殺傷力

1. 開源專案的 E2E 測試包（入門首選，1-2 週）

挑一個你常用的開源工具或公開網站，用 Playwright 寫 15-25 條有策略的 E2E 測試。

  • 重點不是數量，是 README 裡的測試策略：為什麼挑這些 flow、風險矩陣怎麼排、什麼不測與為什麼
  • 加一個 GitHub Actions workflow 讓測試每天自動跑，badge 掛在 README — 「會 CI」從此不用寫在履歷上，看得到
  • 避雷：不要測 demo 網站（todomvc 那種一看就是課程作業），測真實產品才有討論深度

2. API 測試 + 測試報告（後端加分，1 週）

挑一個公開 API（政府開放資料、金融行情都行），寫 contract test + 邊界案例。

  • 展示點：schema 驗證、錯誤處理案例、rate limit 行為 — 這些是「有實戰感」的訊號
  • 輸出一份人看的測試報告（HTML report 或 markdown 摘要），證明你懂「測試結果要溝通」

3. AI 輔助測試的實驗記錄（2026 差異化關鍵）

這是現在最缺、最少人做的類型：拿同一個功能，記錄「純手寫測試 vs AI 生成後人工校準」的差異。

  • 記錄 AI 生成的測試漏了什麼、誤判什麼、你怎麼補 — 這直接展示你的測試判斷力高於 AI
  • 面試時這個專案能撐 20 分鐘的深度對話，而且話題主導權在你手上
  • 寫法參考站內的 AI 測試工作流 SOP，你的實驗可以直接以它為基底

4. 測試小工具（有餘力再做）

測資產生器、bug report 格式化工具、flaky test 分析腳本 — 規模小沒關係，重點是「解決你自己遇過的真實痛點」，面試講起來才有故事。

GitHub 整理的 5 條規則

  1. Pin 3 個以內：面試官只會點前三個，別讓課程作業稀釋主力專案
  2. README 是門面：第一屏要有「這是什麼、怎麼跑、測試策略」，截圖或 badge 勝過千字
  3. commit 記錄要乾淨：一次 commit 一件事 — 面試官會翻 history 判斷你是不是一夜趕工
  4. 能一鍵跑：npm install && npx playwright test 跑不起來的作品集是負分
  5. 私有專案寫成 case study：公司專案不能公開，就寫一頁「情境-做法-結果」的匿名化 case study 放個人頁

面試怎麼講你的作品集

  • 開場 30 秒版本：「這個專案測 X，我最自豪的決策是 Y，過程中最難的 trade-off 是 Z」— 先講判斷，不要先講工具
  • 被問「這是不是 AI 寫的」：坦白分工 —「框架 AI 搭的，測試策略和案例設計是我的，這裡有三個 AI 版本漏掉的案例」
  • 主動把話題導向專案：作品集最大的價值是把面試從「抽考」變成「你熟悉的主場」

避雷清單

  • ❌ fork 別人的 repo 改兩行就放 — 一定會被 commit history 拆穿
  • ❌ 只有 code 沒有 README 的測試策略 — 那只證明你會語法，不證明你會測試
  • ❌ 十個半成品 — 不如一個完整的
  • ❌ 履歷寫了連結但 repo 最後 commit 是兩年前 — 記得面試季前更新一輪

延伸閱讀