軟體測試每週一問：作為一個軟體測試人員經常會遇到程式設計師或者設計人員拒絕修改你提交缺陷的情況，但是往往到最後這個缺陷會被使用者提出，不得已再進行修改，給個人和公司帶來一定的負面效果，那麼如何說服他人認可你提交的缺陷是需要修改的？歡迎大家各抒己見！

        會員cityyard的精彩回答：

        首先，開發方必須提供完整詳細的式樣書和制限事項。式樣書是測試人員測試的基礎，測試人員如果按照式樣書測試得到了不一樣的或者奇怪的結果，那麼必然是bug無疑，沒有任何可以爭論的餘地；如果測試人員執行了式樣書上沒有寫的動作，得到了一個奇怪的結果，那麼首先去制限事項裡面找，如果制限事項寫了，那麼意味著開發者知道這個問題並且還在開發中，那麼OK暫時放過（注意是暫時），如果制限事項也沒寫，那麼再看這個動作是不是使用者可能做出來的動作，舉個例子如果一個軟體的某個命令完全封裝在內部，呼叫時一定會以普通使用者身份執行，那麼測試人員使用root測試出來的問題就是無效的（注意，當然封裝的命令可能因為封裝錯誤用root執行了，但那是另一個bug）；如果測試人員的動作雖然式樣書沒有，但是卻是使用者可以做出來的，那麼抱歉，這個問題必須修改，而且還要圍繞這個被式樣書遺漏的問題進行拓展。

        其次，測試開始前由開發方review測試方的測試計劃，並針對測試方對式樣書的疑問答疑。這一點有兩個好處，一個是開發方可以儘早指出哪裡測試不合理，哪裡測試薄弱，另外也可以減少以後因為雙方理解上的差異帶來的時間浪費。雖然這會佔用一點開發人員的時間，但是磨刀不誤砍柴工。

        第三，建立完備的版本管理系統，這個系統如何建立前面的每週一問已經詳細討論過了，目前要補充的就是，版本管理中必須把式樣書和制限事項一起加進去，開發者釋出了0_0_1版，其中制限事項是檔案數目不能超過1M個，0_0_2版開發者取消了這個制限，那麼必須在釋出作這個版本的同時寫明這一點，測試人員才能據此測試。嚴格的版本管理可以有效減少糾紛，如果測試人員使用0_0_1版測試1M+1個檔案失敗，那麼是無效測試，如果使用的0_0_2版，那麼就是bug必須修復，無可爭論。

        有了上面三條，大部分問題差不多能解決了，但是還是不行，差在哪裡？主要還有兩個問題，一個是測試方可能指出一些跟個人喜好相關的地方，比如測試方可能指出GUI一個警告資訊窗的字型太暗而且不顯眼，不容易被注意到，這類問題無法用上面三條來解決，因為是否容易被看到本身就不好界定；另一個問題就是（尤其是到了測試後期），測試人員連續跑了好幾天測試忽然程式死了，再來一次又沒事了，告訴開發人員這個現象，開發人員也解決不了，因為很難再現，如果是測試環境問題還好，如果真的是軟體缺陷那被使用者遇上就很嚴重，但是這種問題無論是讓QA無休止的嘗試再現還是讓開發者沒頭沒腦的調查都很難說得過去。

        於是我們加上一條
        第四，仲裁機制。QA和開發者並不直接對話去討論一個問題是否要修改，我們首先對開發者實行殘酷的有罪推定，也就是QA報告的問題開發者都必須修改，如果開發者認為無需修改必須給出理由和證據，圍繞這個理由是否成立，QA和開發者雙方展開討論，這個討論必須每一步都使用缺陷管理

        寫到這裡細心的讀者已經發現，題目問的是怎樣去說服，我卻大談測試管理方法。其實我個人覺得，建立一個巨集觀的良好機制比起一個測試者去脣槍舌劍的和開發人員辯論更加有效，我們追求的是什麼，不就是效率麼。因此我個人以為真正的測試人員職責就是報告缺陷，至於這個缺陷是否應該被修復先用機制套，套不上再來仲裁，仲裁過程QA leader全程參與，測試人員要做的只是在仲裁過程中客觀的回答每一個問到自己的問題，至於什麼我認為這個bug必須修之類的話不必出自測試人員之口，正如汽車發動機只需要考慮轉呀轉，具體哪個路口該拐彎也讓發動機來考慮就不必了。