Blog 250/365：【學新知】大家一起來抓蟲，描述軟體Bug的一些撇步
🤔為什麼要寫這篇小記？
QA (測試工程師)一直是讓我很尊敬的職位，因為他們的時間往往被無情的剝奪。以一個軟體開發流程來說，老闆通常只看到「PM規劃、Designer設計、RD開發」，但最關鍵的一步 - 「QA測試」卻往往被忽略。
以過去工作的經驗來說，PM規劃一個月的新功能、Designer 2 - 3週設計、RD 2 - 4週開發，猜猜最後QA測試的時間有多久？一個禮拜，修旦幾勒...是不是有哪個地方怪怪的？
在時間被壓縮的情況下，軟體功能有許多的Bugs沒辦法被有效發現及處理，匆促上線的結果就是不斷在正式網站上(Production environment)進行功能修正(hot ifx)。太多的軟體業術語看不懂嗎，大概就像下方這張圖吧。
這篇《撰寫（回報）Bug的藝術》有幾個在紀錄Bug的實用技巧，原文在這裡：https://www.softwaretestinghelp.com/bug-reporting-get-your-bugs-fixed/，這篇文章只摘要我覺得比較重要的部分。
🤔怎麼描述軟體功能中的蟲蟲(Bugs)？
一個完整的蟲蟲報告，應該包含以下訊息：
► Bug Summary:
1.應簡潔明瞭
2.Bug Summary內容可簡短扼要的點出問題
3.應包含When (哪個時間或狀態)/ what(發生甚麼問題) /how(如何發生)
4.應盡量避免使用一些含糊不清的字眼(ex:"not working properly", "not working as expected" etc.)
► Steps to Reproduce and Attachments
1.盡量找出重複可重現的步驟，一個無法重現的bug其價值並不是那麼的重要
2.在某些bug當中，會有些關鍵性的步驟，因此在描述步驟時，可附加說明(ex:Key point)，提醒RD
3.針對問題描述，可加上預期結果(expect result)與實際結果(current result)以供比對
4.對於較精簡且不是很重要的步驟，若非必要步驟，可簡單描述即可
5.無法使用文字描述，可用附檔輔助 rd釐清問題
6.若有系統的log或是其他紀錄資訊，可一併附上，以助於釐清問題
► Bug Reproducibility
1.一個問題的大或小，可從是否能被重現來參考
2.可以被重現的問題，其priority永遠比其他只能被重現一次，或是偶而才重現的問題還要高
3.找出正確的重現步驟，是一個測試工程師的職責
► Bug Severity
1.嚴重程度是一個問題的影響範圍的表示，影響程度越大，其serverity越高
2.severity的定義如下：
Severity 1 – 非常嚴重，會造成功能停擺，造成該功能無法繼續使用，且沒有其他解決方法 ；例如：所有儲存功能皆無效save鍵就當機了，導致於文件文法儲存
Severity 2 – 高，會造成功能停擺，但是有其發方法可解決；例如：按下save鍵不動作，但是使用CTRL+S可使用)
Severity 3 – 中等
Severity 4 – 低
Severity 5 – 瑣碎的
🤔收穫與啟發
這篇文章中我覺得最實用的就是嚴重性的判斷，團隊中如果沒有對嚴重性的定義有共識，時常就會發生插單的現象，例如「這個很急，不先修會完蛋！」「那個很趕，明天一定要好！」，雖然人性最直覺的反應就是自己的問題最嚴重，但更背後的原因可能是 "團隊根本不知道如何區分嚴重性"，所以每個人都覺得自己遇到的問題就是世界末日。
說清楚、講明白，或許團隊的默契自然就會來....(吧)。
