Testing knowledge Interview
正式進入到測試領域的面試時，大約 50 分鐘內結束。
我的習慣有幾個要領
- 讓人選用最短的時間描述最近一份工作的角色與使用的技能
- 用Open Question 取代制式化的問題
- 不要一開始就給太多提示，觀察人選是否能夠反向提問
- 設定問題要有時限，觀察人選多久進入問題核心
- 結果沒有對錯，而是人選對於問題的掌握與解釋
- 人選對於開發流程的認知與參與程度是關鍵
- 設定一些極端狀況的情境，了解人選的選擇
沒有任何的科系教你如何當QA
人選只會回答前一份工作經驗的內容也只是剛好而已
重要的是，極少數的人選懂得如何歸類問題與測試方法
Open Question 的部分大多會用範圍很廣的方式做開頭，例如：
請利用市面上熟悉的軟體產品，選定一個功能做測試，你會怎麼安排你的測試計畫並交付出貨？
這個問題很廣，廣到人選可能不知道從何開始。對，這就是目的，比起解決問題，我更看重QA是否有能力釐清問題與縮小問題範圍的能力，在問題還沒有清楚的當下，就嘗試提出解決辦法，不一定是正確的解決辦法。
通常具有一定測試經驗的人選，會嘗試歸類測試方法，在適當的時程與資源，選擇適當的測試策略。若要實踐「設定一些極端狀況的情境，了解人選的選擇」這個問題，可以提供以下的例子：
如果只有只有一週時間，盡可能完成手上 1000 條 Test Cases，並決定是否能夠出貨，你會採取的策略與如何決定出貨標準？
Development Process 的理解與參與狀況，是觀察人選潛力的一個指標
QA 跟 QC 不同在於，QA 是任何關係到產品品質的議題，都值得投入心力，因此，QA 除了測試，更需要了解開發流程中，每個節點的用途與角色，因為有些時候，產品的品質問題不僅是程式上的Bug，亦可能是溝通過程中的資訊不對稱造成，譬如說，Spec 不明確、交付下游開發的時程矛盾、Resource 分配等問題，甚至是開發途中有一些 Interruptions 產生，造成功能上的瑕疵…等。
QA 若能掌握開發流程的細節，並且在適當的時機點修正或是溝通，有些事情不需要靠極高的測試覆蓋率，就能輕鬆改善，而且，在需求面上，如果QA 可以及早確認功能的可行性或是限制，也可以避免開發過程中，沒有被考慮到的問題。
一個具有潛力的 QA 多少會更關心開發流程的每個狀態，因為這樣，就能得到更多資訊的在對應的情況解決問題。
Testing knowledge Interview 結論
在這個階段，要觀察的重點如下：
- 釐清問題並歸類問題
- 用在適當的時機，提供實際的測試方式，而不是畫大餅
- 有什麼東西是自動化測試實現不了的
- 建置測試的手法很多，人選是否能說明優缺點，如何讓測試效益最大化
- 嘗試發現問題中的問題（好奇心）
- 看見問題的核心（細心）
- 對於團隊的流程有一定程度的瞭解與參與
