QA 的橫向出路 — 轉 SDET / DevOps / PM / 資安 / 資料的可行路徑
站內講 QA 職涯的文章，大多在講「怎麼往上爬」——Junior 到 Lead、走技術線到 Principal。但我這幾年被問最多的，其實是另一個方向的問題：「Mark，我不是想升官，我是想換跑道，QA 的經驗能帶我去哪？」
這在 AI 讓大家焦慮的 2026 更常見。這篇不談往上，談橫向——從 QA 出發，五條最實際的轉出路徑。每一條我都拆成四塊：你已經有的優勢、要補的缺口、實際要花多久、以及明天就能做的第一步。
先看全局：QA 的能力能接到哪
flowchart LR
QA[QA<br/>產品全局 + 邊界思維 + 品質意識] --> SDET[SDET<br/>測試自動化工程]
QA --> DO[DevOps / SRE<br/>CI-CD + 可靠性]
QA --> PM[Product Manager<br/>需求 + 優先級]
QA --> SEC[AppSec 資安<br/>攻擊者思維]
QA --> DATA[Data QA → 資料工程<br/>資料正確性]
重點先講：QA 最被低估的資產不是「會測試」，是「懂整個產品怎麼運作、還會想壞掉的地方」。這兩件事，很多純工程師反而缺。轉職不是從零開始，是把這個底層優勢接到新技能上。
路徑 1：SDET / 測試自動化工程師（最近、最自然）
- 你已有的：測試策略、案例設計、產品知識——這是 SDET 的一半。很多純開發轉 SDET 反而卡在「不知道該測什麼」，你天生會。
- 要補的：把手寫測試變成可維護的自動化框架——Playwright/Selenium 進階、CI 整合、page object、測試資料管理、flaky test 治理。
- 實際時程：3-6 個月。這是所有路徑裡最短的，因為你只是把既有能力「工具化」。
- 第一步：拿你現在手動在測的一條關鍵 flow，用 Playwright 寫成自動化 + 接進 CI，做成作品。參考站內的 AI 輔助 QA 工作流 SOP，用 AI 加速會更快。
路徑 2：DevOps / SRE（如果你喜歡 pipeline 和穩定性）
- 你已有的：如果你碰過 CI/CD、寫過 pipeline 裡的測試階段、追過環境問題——你已經站在 DevOps 門口了。QA 對「什麼會在生產環境爆掉」的直覺，正是 SRE 的核心。
- 要補的：容器（Docker/K8s）、IaC（Terraform）、監控與告警（Prometheus/Grafana）、雲平台（AWS/GCP）。技術深度要補不少。
- 實際時程：9-15 個月，是這幾條裡技術門檻較高的。
- 第一步：把團隊的測試流程「基礎設施化」——例如把測試環境用 Docker Compose 一鍵拉起、或把 flaky test 的重試/報告自動化。從 QA 的痛點切入 DevOps，最有故事。
路徑 3：Product Manager（如果你更愛「為什麼做」而非「怎麼做」）
- 你已有的：這條路 QA 的優勢最被低估。你每天在讀規格、找漏洞、站在使用者角度想邊界案例——這就是 PM 的日常。你對產品的全局理解常常比工程師還完整。
- 要補的：需求撰寫、優先級排序（RICE 等框架）、跟 stakeholder 溝通、看數據做決策、路線圖規劃。從「找問題」轉成「決定做什麼」。
- 實際時程：6-12 個月，很多公司樂意讓熟產品的 QA 內轉 PM。
- 第一步：在現職主動寫一份「這個功能的邊界案例 + 我建議的優先級 + 理由」的文件給 PM。做幾次，內轉機會常常自己找上門。
路徑 4：AppSec / 資安（如果你享受「把東西弄壞」）
- 你已有的：QA 的破壞式思維 = 資安的攻擊者思維，同一種腦。你找 bug 的直覺，換個方向就是找漏洞。
- 要補的：OWASP Top 10、滲透測試工具（Burp Suite）、常見漏洞原理（injection、auth、XSS）、威脅建模。要補安全專業知識，但思維方式你已經有。
- 實際時程：9-15 個月，建議搭配證照（如入門的 eJPT）增加可信度。
- 第一步：對你在測的產品做一次 OWASP Top 10 自查，把發現寫成一份安全視角的測試報告。這份東西在資安面試裡很有份量。
路徑 5：Data QA → 資料工程 / 分析（如果你做過資料驗證）
- 你已有的：如果你測過 ETL、對過報表數字、驗過資料正確性——你已經在資料領域的邊緣。「資料對不對」是資料工程的核心焦慮，你懂。
- 要補的：SQL 進階、資料管線工具（dbt/Airflow）、資料建模；往分析走則加統計和視覺化。
- 實際時程：6-12 個月。
- 第一步：把團隊某個「人工核對的報表」用 SQL + 自動化檢核腳本取代，做成資料品質監控的小專案。
怎麼選：三個問題
- 你討厭的是 QA，還是這間公司？ 只是環境問題，換公司或往上走更省力，別急著重啟學習曲線。
- 你享受的是「怎麼做」還是「為什麼做」？ 前者往 SDET/DevOps，後者往 PM。
- 哪條路能複用你最多既有優勢？ 複用越多、轉職越快、議價力越強。SDET 通常是複用度最高的起點。
一個誠實的提醒
別為了逃離 AI 焦慮而盲目轉職。 這些領域一樣被 AI 衝擊——SDET 的自動化、DevOps 的 ops、PM 的文件，AI 都在滲透。真正抗跌的不是「轉去哪個職稱」，而是那些 AI 取代不了的底層能力：判斷力、跨域整合、對真實使用者的理解。橫向轉職是拓寬選項，不是逃生艙。想清楚AI 時代自己要成為什麼樣的人，比選哪條路更重要。