測試管理之BUG流程相關建議
關于BUG流程相信大家都已經很熟悉了，并且用起來也得心應手，在此不再贅述。以下對BUG有一些小小的建議，主要針對我們日常工作中沒有注意到的地方說的，建議雖小，但要重視噢。
對于研發經理：
當一個BUG被你審核通過，在派給開發人員時，你應該將BUG的狀態改為“打開”。
審核BUG時你有***權限，可以審核BUG的所有信息是否正確，所以***重新審核一下我們提交的BUG嚴重程度，你有權修改哦。還有類型也可以修改的。
對于軟件工程師：
請開發人員修正后，注明修改后達到的功能效果以及可能影響到哪些其他的功能模塊，還有拒絕或延期的理由。同時***寫上解決的方式或非正常解決問題的原因，對于我們來說這些積累是一筆很大的財富。
如果你正陷入讓測試人員使用bug管理庫的苦惱中，你只要不用其他方法接受bug報告。如果你的測試人員習慣將bug報告用郵件的形式發給你，你只需用一個簡短的消息回復他們：“請將它們輸入到bug庫中，因為我無法追蹤郵件。”
對于測試人員：
請測試人員提交新錯誤時，盡量用最簡潔的語言最清晰的描述出BUG的出處、操作步驟、現象、（建議），并盡量截圖。
盡量減少重現的步驟以達到用最少的步驟來重現問題；這對編程人員來說是很有幫助發現問題根源的。
當你的bug報告以“not repro（不可重現）”打回給你時，先檢查一個步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無法用bug報告中的步驟重現bug時才選擇這個選項。
不要使用完全的大寫形式，那樣會讓人感覺象控訴。不要使用感嘆號或其他表現個人感情色彩的詞語或符號。
不要使用含糊的詞語（例如，好像，似乎）來描述發現的現象。
在提交BUG的標題***行寫上錯誤的總結是非常關鍵的。這要求測試人員編寫的報告要能夠吸引讀者，引起他們的注意，并使和管理層的溝通清晰。
再次強調，在bug report的初稿完成后，測試人員應該反復閱讀它，集中剔除那些沒有關系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關系的細節或者那些在重現錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標。
測試人員在精簡空話的同時或其之后隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該盡量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。
大家都要注意的地方：
當你發現一個BUG，或者正在修改BUG時，請考慮如下問題：
1. 同一軟件中的相似功能是否有相同的問題？
2. 其他的瀏覽器是否有相同的問題？
3. 其他的軟硬件配置是否有相同的問題？
4. 其他的區域（locales）是否有相同的問題？
5. 不同的安排設置是否有相同的問題？
6. 以前的版本否有相同的問題？
希望對你有幫助。
原文地址：http://bbs.51testing.com/thread-77195-1-1.html
【編輯推薦】
