新鮮人轉 QA — 從 0 到第一份工作的 90 天完整計畫
給沒經驗想入 QA 的人。90 天分 3 階段:學基本功 → 做 portfolio → 求職。每週進度、該做什麼、卡關時對策。含科班 / 非科班、轉職、學生不同路線。
💡 本文原刊於 qa.9niche.com,2026-08 併入 9niche.com 懶人包,內容照原文完整搬遷。
目錄
1. 前言
「我想轉 QA 但不知道從哪開始」是我一週收 10 次的問題。90 天能不能進 QA?能 — 但要照計畫走。這篇給你一份能照表操課的 12 週路線。
2. 你適合走 QA 嗎(30 秒自評)
全是 yes → 開始 90 天計畫。
3. 90 天總地圖
每天 1-2 小時 認真學、90 天能拿 junior offer。每天 3 小時 能拿 mid 起薪。
4. Phase 1: Day 1-30 — 學基本功
Week 1: 認識 QA 是什麼
目標:知道你要走的路、不是浪漫想像。
| 日 | 做什麼 |
|---|---|
| 1-2 | 讀 Test Pyramid + 測試類型全圖 |
| 3-4 | 讀 Sprint 中 QA 的位置 |
| 5 | 讀 AI 時代 QA 還有未來嗎 |
| 6-7 | 找 2 個 QA 朋友聊(不一定要面對面、Twitter / LinkedIn 都行) |
驗收:能跟朋友 5 分鐘講清楚「QA 在做什麼」+「為什麼這時代值得入」。
Week 2: 手動測試基本功
目標:會寫像樣的 test case + bug report。
| 日 | 做什麼 |
|---|---|
| 8-9 | 讀 Test Case 撰寫範本 |
| 10-11 | 找一個 app(任何你常用的) — 寫 20 個 test case |
| 12-13 | 讀 Bug Report 撰寫 SOP |
| 14 | 找出該 app 5 個 bug、用標準格式寫 ticket |
驗收:你寫的 case 跟 bug report 給人看、別人能照著重現。
Week 3: Git + GitHub
目標:能用 Git 管理你的 portfolio。
| 日 | 做什麼 |
|---|---|
| 15-16 | 讀 Git for QA |
| 17 | 註冊 GitHub、建第一個 repo(放 week 2 的 test case) |
| 18-19 | 學 commit / branch / PR、跑一次 PR review |
| 20-21 | 把 week 2 的 case 整理成 markdown、push 到 GitHub |
驗收:你的 GitHub 有 1 個 repo 含 test case + bug report、README 寫好。
Week 4: SQL
目標:能用 SQL 查資料、不用每件事問 dev。
| 日 | 做什麼 |
|---|---|
| 22-23 | 讀 SQL for QA |
| 24-25 | SQL Bolt 互動式練習(免費) |
| 26-27 | HackerRank SQL Easy 全做完 |
| 28 | 寫 5 個你自己的常用 query |
驗收:能寫 SELECT、WHERE、JOIN、GROUP BY。
第一個月驗收
✓ 知道 QA 在做什麼
✓ 會寫標準 test case
✓ 會寫標準 bug report
✓ 會用 Git + GitHub
✓ 會基本 SQL
沒達到 ≥ 4 項 → 別進 phase 2,補完再說。
5. Phase 2: Day 31-60 — 做 Portfolio
Week 5-6: 學第一個自動化框架(Playwright)
目標:寫得出能跑的 E2E test。
| 週 | 做什麼 |
|---|---|
| 5 | 讀 Playwright 入門、跑官方 demo |
| 5 | 自己挑一個 app(例如 todomvc.com),寫 10 個 E2E |
| 6 | 讀 Page Object Model 實戰、重構 |
| 6 | 加 GitHub Actions、讓 test 自動跑 |
驗收:GitHub Actions 上你的 test 是綠的、有 README + screenshot。
Week 7: API 測試
目標:會用 pytest 測 REST API。
| 日 | 做什麼 |
|---|---|
| 43-45 | 讀 API 測試實戰(pytest + requests) |
| 46-47 | 找一個公開 API(例如 JSONPlaceholder)寫 15 個 test |
| 48-49 | 加 JSON Schema 驗證、parametrize 測 edge case |
驗收:GitHub 有第二個 repo、用 pytest + requests + jsonschema。
Week 8: AI 工具上手
目標:會用 LLM 加速自己的 QA 工作。
| 日 | 做什麼 |
|---|---|
| 50-51 | 讀 用 LLM 生 Test Case |
| 52-53 | 試 Prompt 範本庫 5 個 prompt |
| 54-55 | 用 LLM 幫你寫 third repo 的 test case 草稿 + 自己 review |
| 56 | 寫 1 篇 blog 講「我這禮拜用 AI 怎麼加速 QA 工作」 |
驗收:能在面試講「我這樣用 AI 工具 + 我會 review 它的輸出」。
Week 9: 第三個 Portfolio 專案(自選 domain)
目標:有個「能說故事」的 portfolio 專案。
第二個月驗收
✓ 3 個 GitHub repo(手動 case、E2E、API)
✓ GitHub Actions 都綠的
✓ 1 篇 blog 講 AI 工作流
✓ README 寫得讓 HR 看懂
6. Phase 3: Day 61-90 — 求職
Week 10: 履歷 + LinkedIn
目標:履歷一頁紙、能進 ATS。
| 日 | 做什麼 |
|---|---|
| 64-65 | 讀 QA 履歷範本與寫法 |
| 66-67 | 寫履歷 1.0、用 phase 2 的 portfolio 當「Projects」段落 |
| 68-69 | 寄給 3 個朋友 review、改 2.0 |
| 70 | 更新 LinkedIn — Headline / About / Projects |
驗收:履歷被資深 QA 看完不會皺眉。
Week 11: 投履歷 + 練面試
目標:投 30+ 份、回 10+ 場面試。
| 日 | 做什麼 |
|---|---|
| 71-72 | 找 30+ 職缺、依「我感興趣度」排序 |
| 73-74 | 一天投 5-8 份、客製 cover letter(用 LLM 加速) |
| 75-76 | 讀 QA 面試 50 題 |
| 77 | 找朋友 mock interview 30 分鐘 |
驗收:第一週至少有 3 場面試邀請。
Week 12: 面試 + offer 談判
| 日 | 做什麼 |
|---|---|
| 78-84 | 每天 1 場面試、面試後立刻寫 retro |
| 85-86 | Pipeline 中至少 1 個 final round |
| 87-88 | Offer 來了 — 不要馬上接 |
| 89-90 | 談薪、簽 contract |
驗收:拿到至少 1 個 offer。
7. 不同背景的調整
科班(電資 / 資工 / 統計)
你已有的:寫 code、Git、CS 基礎
跳過:Week 3(Git)、part of Week 5(Playwright 概念)
省下時間:投入更多 portfolio
非科班(文 / 商 / 醫 / 工)
你已有的:domain 知識(這是你的差異化)
要補的:Week 5-6 多花 2 倍時間(Playwright)
策略:投跟你 domain 相關的公司(醫療 QA / 法律 QA / fintech QA)
學生(大三 / 大四)
時間優勢:每天能 3-4 小時
策略:找 internship、用 phase 2 的 portfolio
半年後直接拿 mid-level offer 不是夢
轉職(30+ 歲、有原工作)
時間挑戰:每天可能只 1 小時
策略:拉長到 6 個月、phase 1 多花時間
優勢:成熟度高、面試時強調「我已經跟人合作過 X 年」
8. 90 天會卡的 5 個地方
卡 1: 學程式痛苦
對策:找 pair programming 朋友、或上 Codecademy 結構化課程。別硬 K 書、會放棄。
卡 2: Playwright 環境裝不起來
對策:用 Docker 跑、跳過 Mac/Windows 環境問題。或直接用 GitHub Codespaces。
卡 3: Portfolio 不知道做什麼
對策:模仿你愛的 app(Notion / Spotify / Twitter)— 不是 clone 全部、是測它的某個 flow。
卡 4: 投 30 份沒回音
對策:
- 履歷加上「used AI in QA workflow」會有奇效(很多 recruiter 用 keyword 篩)
- LinkedIn 直接私訊 hiring manager(不要 cold、先看他的 post + 留言互動)
- 用 referral — Twitter / LinkedIn 找已在公司的人
卡 5: 面試卡「沒經驗」
對策:把 portfolio 當「工作經驗」講:
❌ 爛答案:「我沒有工作經驗」 ✅ 好答案:「我過去 3 個月做了 3 個自動化專案,第一個是 todomvc 的 E2E、第二個是 API 測試、第三個是我用 AI 加速自己工作流的實驗。每個都在 GitHub、CI 都是綠的。」
有 portfolio 就有經驗。
9. 該投什麼公司(依優先級)
新鮮人最該選的公司類型
- ✅ 有 senior QA mentor(你能學)
- ✅ 用現代工具(Playwright > Selenium、GitHub Actions > Jenkins)
- ✅ 有 dev team 願意跟 QA 合作(看面試時 dev 怎麼講 QA)
- ✅ 公司在用 AI 工具(你能繼續學)
該避開的
- ❌ 純手動測試、沒人懂自動化
- ❌ QA 是「按按鈕的」這種文化
- ❌ 面試時 QA 跟 dev 互相 blame
- ❌ Test 沒進 CI、release 看心情
10. 第一份工作該選什麼
如果同時拿 3 個 offer:
前 2 年「學到什麼」> 薪水。差 3K-5K 但能學到的、選後者。
11. 90 天計畫摘要表
| 週 | 主題 | 產出 |
|---|---|---|
| 1 | QA 認識 | 能跟人講清楚 |
| 2 | 手動測試 | 20 個 case + 5 個 bug |
| 3 | Git | GitHub 第 1 repo |
| 4 | SQL | 自己 query 集 |
| 5-6 | Playwright | GitHub 第 2 repo + CI 綠 |
| 7 | API 測試 | GitHub 第 3 repo |
| 8 | AI 工具 | 1 篇 blog |
| 9 | Portfolio 專案 | 完整 README + story |
| 10 | 履歷 | 1 頁完成 |
| 11 | 投履歷 | 30+ 份 |
| 12 | 面試 + offer | 拿到 |
12. 給走完 90 天的 5 句
- 入行只是開始、不是終點
- 第一年比薪水重要的是 mentor
- 承認自己不會、然後補上
- 每個專案都該有 README + story
- AI 是工具、判斷力是你
13. 給走不下去的人
如果 phase 1 走完發現「我不愛 QA」 — 這是好事。比進去後悔好。考慮:
- 對 code 興趣 → 轉 dev
- 對流程興趣 → 轉 PM / PO
- 對 UX 興趣 → 轉 Designer
- 對資料興趣 → 轉 Data Analyst
沒有浪費的 90 天。你會 Git / SQL / Playwright、轉哪都有用。
14. 最後
90 天能不能進 QA — 能、但要照這個表跑。我看過 200+ 個 QA 入行軌跡、走得快的、慢的、放棄的。走得快的人不是聰明、是有計畫 + 不偷懶。從今天 Day 1 開始、90 天後你會驚訝自己變多。
延伸:
- QA 新人第一年技能樹
- 沒經驗找第一份 QA 工作
- QA 學習路線圖
相關連結
一篇講完所有測試類型。Test Pyramid 三層、Smoke vs Sanity 差別、Regression 策略、Shift-left vs Shift-right、現代變形(Trophy、Honeycomb)。
Agile sprint 各階段 QA 該做什麼?什麼時候進場?要不要估點?Definition of Ready / Done 怎麼設?給轉 Scrum 的 QA 的實戰手冊。
AI 時代 QA 工作真實分析。哪些任務 LLM 已經做得比人好、哪些 10 年內不會被取代、QA 該怎麼重新定位、薪資版面變化、給焦慮中的人一份地圖。
相關懶人包
2026 QA 趨勢實戰:我看到的 5 個轉變(AI、Shift-Left、Observability)
從手動 QA 到 AI 輔助、從測試金字塔到測試獎盃。這篇分享我這 10+ 年看 QA 從「測完才知道」到「shift-left + AI」的真實觀察。
2026 QA 面試的 AI 題 — 12 題 + 答題框架(面試官想聽什麼)
2026 QA 面試新增一整類「你怎麼用 AI」的問題。這篇整理 12 個高頻 AI 面試題、每題附面試官真正想聽的點與答題框架,從「你用過哪些 AI 工具」到「AI 生的 test 怎麼信任」。
AI / LLM 功能 Spec Review — 幻覺 / 評估 / 成本 / 法遵 8 個必問
AI 功能 spec review 完整指南。LLM 不確定性處理、評估指標、Prompt versioning、成本控制、安全護欄、法遵(EU AI Act / GDPR)、Fallback、人工 review 流程。
一般聲明
本站提供之資訊僅供參考,不保證其完整性與正確性。使用者應自行判斷資訊之適用性。