QE 實習生面試 問題：練習題與初學者答法

練習能展現小而清楚的測試判斷的題目。先從以下提示開始，不要背誦一長串定義。每題都準備一個直接的開場回答和一個具體例子。

需求與預期行為

• 測試註冊表單前，你會先詢問什麼？
• 如果需求只寫著「接受有效的密碼」，你會怎麼做？
• 如果書面需求與範例畫面不一致，你會怎麼處理？

測試點子與優先順序

• 簡單表單上的哪些檢查你會先做？為什麼？
• 如何選擇接近指定輸入限制的測試例子？
• 如果只有時間做兩項檢查，你會優先做什麼？

重現問題與回報

• 隊友說送出按鈕有時會失效。你會詢問哪些資訊？
• 你會如何撰寫一份讓別人能照著操作的回報？
• 如果問題沒有在你的裝置上發生，你會怎麼說？

合作與學習

• 請談談你的專案團隊曾發現非預期行為的一次經驗。
• 如果有人不同意某個情況是否算錯誤，你會怎麼處理？
• 你會如何學習一個以前沒用過的測試工具？

第一次練習時，每組選一題。先回答問題，再補充術語。例如，問到優先順序時，要說明為什麼先做某項檢查，而不只是列出可能的輸入。

如果職務說明列出特定的程式設計任務或工具，請另外準備。較廣泛的工程實習面試指南可協助你準備；本指南聚焦於如何說明軟體品質工作。第一輪練習結束後，標記哪些回答需要更清楚的例子。

完整的初學者答覆會交代情況、說明你實際採取的行動，並以觀察結果或合理的下一步作結。你不必描述正式上線產品發生的事故。以下兩個例子示範如何把有限的經驗連結到具體測試任務。

範例：說明課堂作業中的貢獻

提示：「請談談你曾協助檢查專案品質的一次經驗。」

「在一項課堂作業中，我們小組做了一份任務清單。我負責檢查編輯流程。我和隊友先記下預期行為，接著試著更改任務名稱、將名稱留空，以及取消編輯。我發現取消操作仍會更改畫面上顯示的名稱。我記錄了操作步驟，也說明取消和儲存之間的差異。隊友調整了編輯處理方式後，我重做了相同的檢查。在那個版本中，取消操作會保留原本的名稱。接下來，我會檢查其他可編輯欄位的行為是否一致。」

請留意範圍：回答者指出一項自己的貢獻和一項觀察結果，沒有聲稱測試了整個應用程式。依照你實際做過的工作調整這個架構。STAR 方法可以協助你整理經驗題的回答，但行動內容要具體對應你的角色。

範例：一邊思考一邊說明如何測試註冊表單

提示：「你會如何測試這份註冊表單？」

「我會先釐清怎樣才算註冊成功，以及哪些欄位是必填。假設雙方同意的規則是密碼至少要有八個字元，我會先使用其他資料都有效、且密碼剛好八個字元的情況，再與七個字元的情況比較。我會檢查顯示訊息，以及帳戶是否建立，而不只根據畫面有沒有變化來判斷。我也會詢問已註冊的電子郵件應如何處理。如果時間有限，我會優先檢查主要註冊流程和一項必填欄位，再說明哪些檢查還沒完成。」

這個假設在例子之前就已說明，因此面試官可以修改它。如果對方問「為什麼是八個字元？」，回答這是根據假設的需求，而不是通用的密碼規則。練習回答這個追問時，不必從頭重講整段答覆。

先釐清預期行為；如果面試官希望你繼續作答，再說明一項暫時假設。「我會全部都測」沒有提供起點。附上理由的小例子，更容易討論和修正。

遇到「測試使用者名稱欄位」這類提示時，可以按照以下順序回答。這些只是用來口頭分析問題的示範選擇，不是完整的技術測試課綱。

這類問題讓你有機會把非預期結果說明清楚，讓沒親眼看到的人也能理解。在推測原因之前，先交代操作、預期行為和實際觀察到的行為。

Mozilla 的錯誤撰寫指南是為 Bugzilla 的錯誤回報情境撰寫，建議提供精確的重現步驟、預期結果與實際結果，並將觀察和推測分開。將這種回報方式應用於這道面試練習題。

範例：編輯任務的錯誤回報

標題：取消任務名稱編輯後，畫面上顯示的名稱仍會改變
情境：課堂作業的任務清單專案，正在檢查的版本
初始狀態：有一項名稱為 Read chapter 2 的任務
步驟：
1. 開啟該任務的編輯表單。
2. 將名稱改成 Read chapter 3。
3. 選擇 Cancel。
預期結果：任務仍顯示 Read chapter 2。
實際結果：任務顯示 Read chapter 3。
觀察範圍：在本次工作階段中依照上述步驟操作後觀察到。
尚未檢查：重新開啟頁面後，變更是否仍然存在。

說明預期的依據：在這個練習中，團隊同意 Cancel 應捨棄尚未儲存的編輯。如果沒有這項共識，在認定違反需求之前，先詢問 Cancel 預期的作用。

將可能的原因分開說明。「按下 Cancel 後，畫面上顯示的名稱改變了」是觀察結果。「應用程式太早儲存」則是需要調查的可能解釋。如果面試官要求你提出假設，可以把它說成待驗證的可能性，接著說明哪些證據能支持或推翻它。

有效的回報也不會含糊地描述發生頻率。如果你只試過一次，就明確說明。如果另一次結果不同，記錄差異和相關條件。回答最後可以提出下一個有用的檢查，例如重新開啟頁面；不要承諾尚未調查過的修正。

說明你試過什麼，並詢問缺少的情境資訊。無法重現問題，會縮小目前觀察到的範圍，但不能因此判定原本的回報是否有效。

範例：問題沒有在你這裡發生。你可以說：「我在手上的版本依照列出的步驟操作後，按鈕成功送出了表單。我們可以比對初始狀態、輸入內容和版本，再一起重做相同的操作順序嗎？」如果原回報者使用不同的環境，先記錄差異，再改動多項條件。

根據缺少的資訊，選擇接下來的回應：

• 步驟不清楚：請回報者示範操作順序，包括緊接在問題發生前做了什麼。
• 初始狀態不同：先約定相同的初始狀態，再重做這些步驟。
• 行為偶爾才發生：記錄嘗試次數和條件，也包括問題沒有發生的嘗試。
• 你沒有存取權限：說明限制，並詢問誰能檢查相關證據。

範例：隊友不同意預期行為。你可以說：「我們同意表單接受了這項輸入，意見不同的是它應不應該接受。我們可以確認需求，或詢問負責做這項決定的人嗎？」這樣能指出待決定的事項，而不會把討論變成對隊友的評斷。

如果開發人員要求更多資訊，直接回應對方的要求。你可以說：「我有操作步驟和畫面上顯示的訊息，但還沒檢查重新整理後會發生什麼事。我可以補上這項觀察。」如果你發現原本的預期有誤，請更正回報，並說明是什麼改變了你的理解。

不熟悉某個技術術語時，可以簡短回答：「我還沒用過這個。可以請你說明希望我用它完成什麼任務嗎？」如果相關，再把它連結到你了解的事物。不要用猜測取代不知道的答案，還把猜測說得像確定事實。

選擇一個能區分你個人工作與團隊工作的例子。如果能誠實說明任務，並描述你實際做過的檢查，課堂作業、個人應用程式或志工網站都可以作為素材。

面試前，為一個專案整理一份簡短的證據筆記：

• 你在檢查什麼行為？
• 你個人做了什麼？
• 你觀察到或記錄了什麼？
• 如果有更多時間或權限，你接下來會檢查什麼？

如果目前沒有合適的經驗，可以在自己擁有或獲准測試的專案上做一個小練習。寫下預期行為，試一種一般輸入和一種無效輸入，再記錄結果。討論時要說明這是練習，不要把短暫探索說成自己曾負責已發布產品的品質。

面試結束時，可以問一些能了解實習生如何學習和貢獻的問題：

• 「團隊如何審查實習生的測試點子或錯誤回報？」
• 「我會先學哪些工具？團隊如何協助新人熟悉工作？」
• 「需求不清楚時，誰會協助實習生釐清？」
• 「什麼樣的初期貢獻會對團隊有幫助？」

根據面試官已說明的內容選兩題。如果先前提到過指導或帶教，可以延續這個話題：「你提到會一起檢視回報。通常會著重審查哪些部分？」至於這類對話的準備方式，請參考如何準備實習面試。提問要與職務相關，不要照背通用的面試結尾話術。

使用 SayNow AI 練習如何說出你的推理。在 SayNow AI 的AI 模擬面試中，AI 會在語音對話中扮演面試官、提出追問，並在你完成後提供分數和書面建議。回饋涵蓋流暢度、內容結構、情境契合度和目標達成度，但不會檢查技術答案是否正確。

先從一般求職面試情境開始，練習介紹你在專案中的貢獻。大聲回答、回應一個追問，再帶著一個目標閱讀回饋：讓自己的行動更容易被辨認。接著用更精簡的開場和更清楚的結尾觀察，再回答一次。

把修訂後的架構用在 QE 練習題上。核對課堂作業、題目中說明的需求或適當的審閱者所提供的技術細節，並透過練習改善說明方式。

在求職面試情境中練習口頭回答。

進行一場簡短的模擬面試，練習因應不同任務，而不是反覆回答同一題，直到聽起來像背好的答案。先準備一道經驗題、一項有歧義的需求，以及一份需要說明的回報。

1. 提出你的專案例子，並指出你個人的貢獻。
2. 針對需求提出一個釐清問題，必要時再說明一項假設。
3. 選擇兩個測試點子，並說明預期結果。
4. 透過步驟、預期行為和觀察結果，描述一項出乎意料的結果。
5. 回答一個改變單一條件的追問，例如時間變少或初始狀態不同。
6. 最後提出兩個關於團隊審查流程和學習支援的問題。

留意回答從哪裡開始偏離題目。如果大部分時間都在描述應用程式，就把你的判斷移到開頭。金字塔原則可協助你先說重點，再補充細節。如果你也需要練習動機和時間安排，可以參考較廣泛的實習面試問題指南。

回答 QE 實習生面試問題時，每個回答都要清楚表達一項判斷：你會檢查什麼、這為什麼重要，以及結果能告訴你什麼。今天的練習結束前，把最不清楚的回答再改善一次，然後記下還需要研讀的技術問題。