如果developer return了你的defect

如果developer return了你的defect，你會怎麼做？

return的原因通常有那麼幾種：

1. can not reproduce
2. Need more information

3. Scenario is invalid

4. Limitation
5. Work as designed

對策：

1）如果是can not reproduce，原因很多。最多的情況是在新的build中已經修複了該defect。根據developer返回的資訊，重新驗證該defect的有效性。如果該defect確實不能重現，我會選擇cancel它。如果再次遇到該defect涉及的問題，reopen之，試圖找到原因，將資訊補充到defect的描述中。

當然這種情況，最能描述現實情況的是，developer要將該defect設定為resolved/indirectly fixed。不過我沒有特別堅持過。

也有developer會認為你提出的問題，是根本不可能出現的情況，他們這一塊兒的代碼不可能有問題，多數會告訴你環境有問題。一半一半吧。不過作為測試人員，自然不能輕易放棄。把可能的環境問題重新確認一遍，是環境有問題呢，就cancel這個defect；不是呢，就將確認的過程和log 檔案提交給developer做進一步的判斷。當然，如果某個環境問題很常見，如果對客戶很重要，則要麼寫文檔讓客戶遇到問題可以查詢；要麼在程式中做出檢查，做出預防。

2）如果是Need more information，說明defect中提供的資訊不足以使developer明白髮生了什麼事，並做進一步的investigate。這個時候，多數是會根據反饋，提供更多的資訊，例如發生問題的時候的環境、log檔案等。

一般來說，FVT遇到這種情況比較少；SVT比較多。大概也是FVT的環境相對簡單，只要是有經驗的測試人員，都會根據情況提供足夠的環境資訊和steps to reproduce；而SVT的環境，developers自己平時也接觸的比較少，可能很難立即判斷出現問題的原因。

3）Scenario is invalid，也是會有的。可能在用之前release的scenario在測試，或者需求變更了，scenario就會變成invalid了。像是這種情況，經過溝通和確認，cancel即可。

4）Limitation。對於一個Web應用，limitation多數是third-party limitation，可能來自應用伺服器，瀏覽器，rich editor，feed reader等。其實是不是limitation，是看問題的重要性，是否值得解決。如果很重要，自己會在應用中開發相應的功能或者想辦法繞開；如果沒有那麼重要，則會說以effort、risk等來說，沒有辦法解決。這個時候，通常一線測試人員會提供自己的觀點，而architect或者mgmt team會review之後做最終的決定。

5）Work as designed，這是最辣手的情況。有些developer會說，designer就是這麼設計的；有的會說過去一直是這樣的，從來沒有客戶抱怨過；有些會說我寫個tech notes給客戶好了。

我心裡會說designer的設計本來就是錯的啊；沒有客戶抱怨，也許是客戶還沒有使用，並不說明你現在的狀態就是對的啊；事實上哪裡有喜歡看tech notes的客戶啊。不過我一般想想，很少說出口，頂多寫在defect的comment中

對於軟體項目而言，品質不是唯一的標準，時間和cost都是成功的因素。我會選擇尋找進一步的證據，來說服developer接受我的觀點。我會諮詢我信任的developer對這個問題的看法，也會在必要的時候請求architect的協助，來界定問題的必要性和重要性。PM倒是很少找的，反正他們會定期review所有被置為work as designed的defect。我就遇到過一次，當我正在尋求證據的時候，release manager出手了，她的一句comment，就改變了那個defect的命運。