品質工程師面試會問哪些問題？

面試官會先評估判斷力，再談工具。你應準備說明如何決定一項從未見過的功能需要測試什麼：閱讀需求與程式碼變更、找出風險最高的路徑、選擇哪些檢查應在單元、整合與端對端層級執行，以及決定哪些項目保留人工測試。接下來幾乎總會反過來問：你不會測試什麼，以及原因。若應徵者能說明低風險的設定變更只需進行冒煙測試，而不必執行完整迴歸測試，就能展現該職位所需要的判斷力。

• 測試金字塔。大量快速的單元測試、較少的整合測試，以及少量的端對端測試。後續問題：團隊若將金字塔倒置，會出現什麼問題？
• 風險導向測試。依失敗的可能性與影響排定優先順序，並能向產品經理解釋排序依據。
• 測試設計技術。等價類別劃分、邊界值、決策表與狀態轉換；你可能需要將其中一種方法套用至具體的輸入欄位。
• 非功能性測試。效能、無障礙與安全性的基礎知識，以及判斷何時應將各項納入範圍。
• 退出準則。如何判斷版本已準備好發布，以及期限已到但尚未符合準則時該怎麼做。

只要問題允許，就以自身工作的具體實例作答；策略問題會依答案的具體程度評分。

你每天都在進行自動化，因此可能預期面試官會詢問工具。但他們實際會問的是結構，所以本節涵蓋能看出你的自動化成果究竟經過工程化設計，還是僅僅逐步堆積而成的問題。

• 框架設計。測試與應用程式之間的分層（驅動程式、頁面物件或畫面模型、API 用戶端）、共用固定資料、測試資料管理、報告機制，以及新進工程師如何在不複製舊測試的情況下新增測試。
• 不穩定測試。最常見的問題。先診斷再重試：時序與隱式等待、測試間的共享狀態、對執行順序的依賴、環境差異，以及非同步行為。請說明你會隔離什麼、刪除什麼，以及如何避免整套測試遭到忽視。
• API 與契約測試。直接測試服務、驗證結構描述，以及透過消費者驅動契約，在端對端測試之前發現破壞性變更。
• 工具問題。Selenium、Playwright、Cypress 或行動裝置框架；REST 用戶端；負載測試工具。相較於你使用哪一種工具，面試官更在意選擇原因及其限制。
• 程式設計。預期要使用 Python、Java、JavaScript 或 C# 撰寫小型測試或公用程式，也會被問到如何測試具有多種邊界情況的函式。

把答案串聯起來：清楚分層的框架能讓不穩定測試更容易診斷，而契約測試則能讓端對端測試層維持精簡。

資深職位的多輪面試會直接給你一個情境。典型例子是：一位應徵醫療軟體公司資深職位的品質工程師得知版本將在兩天後發布、端對端測試套件已連續一週顯示失敗，而開發人員聲稱這些失敗是環境問題。出色的回答會先依原因區分失敗，再討論是否發布：閱讀失敗資訊、將環境問題與真實缺陷分開、確認失敗的測試是否涵蓋本次版本中的變更，並向版本經理提供風險說明，而不是簡單回答可以或不可以。面試官評估的是分類處理與溝通能力。

其他常見情境包括：設計 CI 關卡，讓提取要求執行單元與契約測試，速度較慢的測試套件則按排程執行；管理測試環境與測試資料，避免測試依賴單一共用資料庫；決定如何測試你無法控制的第三方整合變更；回報開發人員有異議的缺陷；以及衡量品質，但不把覆蓋率變成追求的目標。每種情況都應先說明限制條件、選擇一種機制，並解釋其代價。

若能在有人追問的情況下把這些答案大聲說出來，回答品質會顯著提升；這正是模擬面試模式的用途。其他職位的題庫則整理在依職位與主題分類的面試問題中。

對於對話式面試，只要遵守誠信界線，就可以。SubcueAI 的原生 macOS 與 Windows 桌面應用程式會擷取系統音訊與你的麥克風聲音，並在本機浮動視窗中顯示簡短的回答建議。因此，當面試官詢問你會如何診斷不穩定的測試套件時，你可在說明自身經驗的同時，從螢幕上查看檢查清單。瀏覽器擴充功能則支援 Chrome 與 Edge 中的瀏覽器分頁通話，且只會擷取會議分頁的音訊。不會有機器人加入通話，也不會在會議頁面中注入任何內容；設定方式請參閱教學頁面。

限制包括：居家作業、受監考的程式設計任務、螢幕錄影，以及公司管理的筆記型電腦均不在適用範圍內；若現場練習要求你在他人監督下撰寫測試，也必須由你自行完成。SubcueAI 創辦人 Aaron Cao 將產品描述為提示你已掌握知識的工具，而不是照著念的腳本；因此，它會根據你的履歷與個人措辭運作。請先載入該履歷；個人資料位於履歷建立工具中。