close
今天讀到一篇關於撰寫Bug的藝術，來記錄一下
原文網址：The Art of Bug Reporting: How to Market and Get Your Bugs Fixed?
如何寫一個好Bug？如何描述一個Bug？這是一個老生常談也是一個很重要的議題，
因為bug 描述的品質，關係到問題是不是真正有被看到，真正的問題有被修復的關鍵，但往往也很容易被測試人員給忘記，
因此看到這篇，真有點心有戚戚焉，來記錄一下我看到的部份。
【以下部分有部分為文章內文，及我個人的一些經驗，這不是聖經，每個單位有他的遊戲規則，看看就好，就當是個參考，但建議還是看原文比較好 ...】
- “The best tester isn’t the one who finds the most bugs or who embarrasses most programmers. The best tester is the one who gets most bugs fixed.”
- 一個好的測試人員不適發現最多的bug或照出誰是不好的程式設計師，最好的測試員是找到最多可被修復的Bug
- Bug report上的問題都應當被修復嗎?答案是"否"
- Bug是否要被修復，需視情況而定，RD並非要照單全收，對於使用者有直接且重大的影響當然要修復，至於非直接重要的問題，可在進行討論進行篩選後再修復
針對Bug report，有個很重要的觀念就是 ==> 看到 Bug要針對問題深入探索，盡可能找到bug發生的真正原因
大部分的測試人員，找到bug會異常的興奮，或是有時為了時效性，就很開心的report了bug，卻忽略了針對Bug進行更深入的探索，反覆的測試，針對bug找出盡可能地找出真正的root cause，
在經過反覆的測試，我們可以找出一些資訊，附加到Bug當中，將對於修復bug將有所幫助
- Bug Report應包含下列訊息：
- Bug Summary (Bug的描述)
- Steps to reproduce (重現的步驟)
- Attachments (Snapshot, Log files etc.,) (附檔：螢幕擷取圖片、Log紀錄...等)
- Bug reproducibility(bug 可被重現的機率 ex:100% or 4/5)
- Bug Severity(Bug的嚴重程度)
- Software Version, Environment Information (軟體版本資訊、測試環境..等)
- Other information based on organizational requirements.(其他相關的資訊...例如：發生時的現場條件)
以下針對幾個比較重要的訊息進行說明：
#1. Bug Summary:
- 應簡潔明瞭
- Bug Summary內容可簡短扼要的點出問題
- 應包含When (哪個時間或狀態)/ what(發生甚麼問題) /how(如何發生)
- 應盡量避免使用一些含糊不清的字眼(ex:“not working properly”, “not working as expected” etc.)
#2. Steps to Reproduce and Attachments
- 盡量找出重複可重現的步驟，一個無法重現的bug其價值並不是那麼的重要
- 在某些bug當中，會有些關鍵性的步驟，因此在描述步驟時，可附加說明(ex:Key point)，提醒RD
- 針對問題描述，可加上預期結果(expect result)與實際結果(current result)以供比對
- 對於較精簡且不是很重要的步驟，若非必要步驟，可簡單描述即可
- 無法使用文字描述，可用附檔輔助 rd釐清問題
- 若有系統的log或是其他紀錄資訊，可一併附上，以助於釐清問題
#3. Bug Reproducibility
- 一個問題的大或小，可從是否能被重現來參考
- 可以被重現的問題，其priority永遠比其他只能被重現一次，或是偶而才重現的問題還要高
- 找出正確的重現步驟，是一個測試工程師的職責
#4. Bug Severity
- 嚴重程度是一個問題的影響範圍的表示，影響程度越大，其serverity越高
- severity的定義如下：
Severity 1 – Show Stopper – for bugs that are catastrophic, without being fixed the user will not be able to continue using the software and there is no possible work around(非常嚴重會造成功能停擺，造成該功能無法繼續使用，且沒有其他解決方法 ；例如：所有儲存功能皆無效save鍵就當機了，導致於文件文法儲存)
Severity 2 – High – for bugs similar to Severity 1, but there is a work around(會造成功能停擺，但是有其發方法可解決；例如：按下save鍵不動作，但是使用CTRL+S可使用)
Severity 3 – Medium (中等)
Severity 4 – Low
Severity 5 – Trivial.
身為一個測試人員，就是在重現使用者的狀況，因此在測試時應站在客戶的立場，模擬客戶的行為與需求進行測試。
應盡量鍵少這幾種BUG的狀況：“Cannot Reproduce” or “Need more Info” or “Not a Valid Bug” or changes in severity as low as possible,
以下是我個人的碎碎念時間：
- Bug不會平白無故跑出來，也不會平白無故地失蹤，事出必有因，一個QA要有無比的耐心與愛心，才能找出真正的問題 。
- 一個測試人員，應多練習如何表達問題，將bug做清楚的描述，將有助於縮短找問題的時間。
- 每一個Bug都有它的價值，不要輕易地忽略它。
- 與其找出一千個Bug，不如找到一個對產品有幫助的關鍵Bug。
Jo 2015.11.13
文章標籤
全站熱搜
留言列表
軟體測試 (1)
