測驗完成后還有bug，測驗人員肯定是有責任的，第一時間要趕緊處理而不是著急甩鍋，但是這口鍋全部扣測驗身上，明顯也是不能接受的，關鍵在于測驗人員需要找出足夠的證據來保護自己，
或許很多人會說測驗不可能發現所有的bug，但是這句話在公司老板聽來不過借口而已，軟體質量由研發團隊共同保證，測驗人員是研發團隊的一份子，而且還是專門負責質量的，你說bug跟你沒有關系，怎么也說不過去，
所以出現bug后，不要直接甩鍋，這樣讓人感覺在逃避問題，第一要緊事情是處理bug，盡量減少對用戶的影響；只要用戶影響不大，即便有責任后果也不會太嚴重，
那么是不是這口鍋就會全部扣測驗身上呢，這樣明顯也是不能接受的，測驗人員需要找出足夠的證據來保護自己，所以第二，我們一定要對測驗后出現的bug進行分析并回溯：
（1） 通過回溯確定問題的產生原因，問題的責任認定基本就清楚了
問題回溯一般從bug的引入階段，bug的產生原因，bug的遺漏原因等幾個方面去分析，例如：
- Bug如果是需求階段引入的，需求本身有遺漏/描述不清楚，那么主要是產品人員的責任，但是設計、開發、測驗人員沒有評審出問題，同樣也有責任
- Bug 如果是開發階段引入的，測驗人員設計用例的時候沒有考慮到，那么主要是測驗人員的責任，但是測驗用例同樣是要經過開發、產品的評審才會使用的
- bug同樣是開發階段引入的，如果bug是由于開發修改bug的時候引入了新的bug，恰好那個用例之前測驗過，不會再重新測驗了，這樣的遺漏主要責任就在開發，修改bug控制影響范圍是開發必須做到的，但是測驗人員可以沒有做到代碼看護的事情
- 再或者產品人員變更需求后，只是告訴開發要改，但是沒有同步給測驗，造成測驗漏測，這就是專案研發流程有問題了，專案經理要負主要責任，
通過上面幾個例子可以看出，bug的產生有很多種可能的原因，一般情況下，在專案組中不會刻意的強調誰要負主要責任，為了團隊的團結，大部分情況下都是產品、開發、測驗共同承擔責任，
（2） 回溯并不是為了推脫責任，根據問題原因提出改進措施才是最終目的，
其實出現問題并不可怕，吃一塹，長一智才最重要，針對上面分析的那些問題的原因，需要制定出對應的改進措施，建立可以量化的改進任務，并指定特定的負責人來跟進，避免類似的問題再次發生，
為了減少測驗人員背鍋的可能，最后提幾點小建議：
（1） 做好充分的測驗計劃
按照正常的測驗流程（測驗方案、測驗用例、測驗執行、缺陷回歸）來評估測驗需要的時間，有時還要預留一些冗余的時間，以處理突發情況，在專案排期時要盡可能的爭取足夠的測驗時間，這樣才能保證在測驗程序中能夠有條不紊的進行，
（2） 測驗程序中的所有作業必須有資料記錄，不能口頭傳達，
很大測驗人員怕麻煩，或者自認為跟產品開發關系好，一些bug通過口頭和開發人員說一下，但不提交缺陷報告；或者bug回歸不通過怕面子過不去，不給打回；開發人員說這不是bug/不重要/不同修改，然后bug就不提了，等等，這些行為平時看起來無所謂，還省時間，但是到了出問題的時候，就是自己埋下的禍根，到時線上出問題了，你說當時測驗過，但是誰誰說不用改，口說無憑！
（3） 測驗結束后的總結需要認真撰寫
正常來說，測驗結束后測驗人員對于軟體質量一定有自己的判斷，是否達到質量要求，是否發布上線，哪些地方由于環境、資料等各種原因沒有驗證充分，還存在風險等等，都需要明確的寫出來，例如：在測驗程序中出現特殊情況，如開發的版本轉測驗時間延遲，需求變更等，導致時間不夠測驗不充分，你可以在測驗報告中建議延期發布，如果專案組要求必須發布，那你就在測驗報告中寫明這些問題，導致測驗不充分，哪些地方會有風險，（這些理由如果在測驗報告中不寫，在問題發生后你再來提，就是“事后諸葛亮”，別人會認為你只是在找借口）
（4） 提升自己的技術能力
提升自己的業務分析能力和用例設計水平，讓自己寫的測驗用例能否盡可能的把需求覆寫全面一些，各種正常例外的情況考慮齊全，就不容易出現漏測；再者，提升各種代碼和自動化工具的能力，撰寫一些自動化的看護腳本，這樣即便出現開發修改代碼改出新問題，也能夠及時發現，提高產品的質量，
最后感謝每一個認真閱讀我文章的人，看著粉絲一路的上漲和關注，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：
這些資料，對于【軟體測驗】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴上萬個測驗工程師們走過最艱難的路程，希望也能幫助到你!
在我的QQ技術交流群里（技術交流和資源共享，廣告勿擾）
可以自助拿走，群號：175317069 群里的免費資料都是筆者十多年測驗生涯的精華，還有同行大神一起交流技術哦
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/292882.html
標籤：其他