這位QA主管是我新到職之後，第一個覺得哪裡怪怪的人，他溝通時不看對方，說話含糊不清，讓人難以理解，我以為是我的問題，私下問了一下，全公司都知道是這個狀況，但更令人驚訝的是，這間公司的QA團隊竟然沒有建立測試案例（Test Case），而且也沒有在分 Bug 的嚴重性等級，我就感到十分好奇，你怎麼進來的？
原來，他和老闆一樣，都是國內軟體大廠出來的，但我覺得這種QA主管的能力只有到「想怎麼測、就怎麼測」，我在這家國內軟體大廠也認識一些人，於是發訊息詢問了一下，原來這位QA主管，當初只是在這間軟體大廠裡做兼職的人力派遣，沒有完整的產品測試流程訓練，就是單純的派遣執行人員。
打聽完之後，也不想要去問老闆當初怎麼面試他，或是怎麼讓他進來的，而今天RD還自我解嘲地說：「只要打開我們的APP，手機就會變成暖暖包哦！」的情況，我大概也知道，應該是這位QA主管不知道怎麼和開發團隊溝通軟體品質這件事了……。
老實說，RD 的這種笑話實在讓人笑不出來。因此，我當時就決定，要慢慢地「調教」這位 QA 主管。畢竟，身為前軟體驗證工程師，我自認在教導軟體測試這件事情上，比絕大多數的產品經理更有說服力。
畢竟，一日 QA，終身 QA 啊……
鬼故事就分享到這邊，不然怕人家知道他的黑歷史，可能又會變成了茶水間的八卦閒聊了。
當產品經理遇到 Bug 時應該怎麼辦？
當產品經理在工作中發現Bug時，通常應該先進行以下處理：
- 確認問題點：產品經理應該自己測試，確認 Bug 的問題點和重現方式，以便向開發和測試團隊提供更準確的資訊，不要亂報 Bug！
- 同步給測試工程師與開發工程師：確認問題後，產品經理應該要把 Bug 狀態同步給測試、開發團隊，因為測試工程師能夠判斷該 Bug 是否已經包含在測試範疇內，如果，Bug 不在現有的測試案例 (Test Case) 中，測試工程師會新增相關的測試案例，並擴大測試範圍，以避免相同的問題在未來版本中重現。
- 在系統上建立 Bug 報告：這時需要在系統上建立 Bug 追蹤單，以確保問題被正確記錄和追蹤。
- 研究 Bug 來源：如果 Bug 重現步驟已經在測試案例 (Test Case) 中，那麼測試、開發團隊需要一起研究能重現 Bug 的操作方式，找出為什麼這個 Bug 會被觸發。
- 評估修復優先級：根據 Bug 的嚴重性和優先級進行評估，決定修復的時間和順序，高優先級的 Bug 通常會優先處理，特別是對用戶體驗或系統穩定性有重大影響的問題。
Bug的種類，通常就是這幾種
功能類的 Bug (Functional Bugs)
功能性 Bug 是指「執行功能」時出現的問題。例如，按鈕點擊後無反應、搜尋功能無法使用等等，或是 APP 突然閃退。
測試時，需要觀察該功能與其他功能是否存在差異，並考量使用者的意圖，或直接查看產品經理的規格文件，有時候，這個功能設計本來就是如此，而並非壞掉，只是產品經理被老闆壓著規劃出這個反人類的設計出來……。
這種 Bug 你需找到「明確」證據來證明功能不正常，才能確定它是 Bug，例如，某功能在特定情況下能正常運作，但在其他情況下卻失效了。
記得！要截圖、錄音、抓log檔。
內容類的 Bug (Content Bugs)
內容性 Bug 指的是APP 或網站上的文字、圖片、連結等等與內容有關的問題，例如：損壞的連結或圖片、缺少文字或圖片、缺少翻譯。
例如，某些按鈕顯示不同語言，或搜尋結果頁缺少某些內容，儘管搜尋功能本身正常，但看起來就是少了什麼。
小考題：你認為，網站或 APP 上的文字拼寫錯誤，算不算是 Bug 呢？
在某些團隊中，拼寫錯誤可能被歸類為「文字錯誤」或「內容問題」，但重點是這個「拼寫錯誤」需要被記錄、追蹤並修正，以確保網站或 APP 的品質與可信度。
想像一下，當你看到一篇文章，僅看前三行就發現錯字，你會對這篇文章有信任度嗎？
視覺類的 Bug (Visual Bugs)
視覺性 Bug 與 APP 或網頁的畫面設計有關，例如：文字或元素錯位、在不同裝置上顯示異常（尤其是自己刻的 RWD 前端）、文字或圖片重疊或被切割。
不過，當內容或視覺性 Bug 影響到功能時，應該視為功能類的 Bug 來建 Bug 單追蹤。
例如，在手機版的畫面中，有一個文字連結點擊沒反應，將畫面解析度切換到桌機版本時，又變成這正常，這樣影響「超連結」的功能，應被視為低嚴重性的功能性 Bug。
重複性的 Bug
當內容或視覺問題在不同頁面或位置重複出現時，僅需開出一張 Bug 單即可，例如，多個商品頁面上的產品圖片損壞時，只需提交一個 Bug 追蹤單號就好。
另一方面，若是「看起來」同一個功能，經過你的「確認」那麼也可以只要開一張 Bug 單即可。
但是，這樣的 Bug 單上雖然是說明它是同一個 Bug，但是，必須要寫清楚它的「範圍」為何，因為，你最後也要在這個「範圍」去驗收 Bug 修好了沒有。
這樣的主要目的，就是好追蹤，另一方面，就是避免工程師不爽你同一個問題開那麼多張 Bug 單做什麼？
Bug的優先級分類
通常，我們會把 Bug 的問題區分完它的類別之後，還會針對它去做嚴重性的分類，例如，按下這個按鈕居然會讓 APP 閃退，這個造成使用者無法使用產品，或是電商平台的結帳金流壞了，用戶沒有辦法付錢，那麼，這些例子的問題，都是屬於「Critical issue」，也是目前最重要、最嚴重的問題。
當然，每家公司都有自己的制度，可以通過內部討論來定義每個Bug的優先級
然而，台灣的許多老闆缺乏對問題嚴重性進行分類的概念，只會說「什麼都很重要，每個問題都要修好」，因此，當遇到這樣的老闆時，需要與他進行有效溝通。
而 Bug 為什麼要分類，其實講白了，就是公司資源要轉移的問題，畢竟工程師只有這些人、這些手，他不可能同時一邊開發新功能、再另一邊修改 Bug。
通常，Bug可以按以下方式進行分類：
- 低 (Low)：影響較小的 Bug，例如 APP 出現一些小錯誤，不影響使用體驗，能以簡單的方法解決。
- 高 (High)：這類 Bug 嚴重影響使用，雖然不會讓主要功能完全失效，但也沒有簡單的解決方法。
- 致命 (Critical)：最嚴重的 Bug，會影響核心功能運作，例如結帳無法完成或 APP 閃退，這類問題對使用者影響最大。
- Known issue (已知問題）：通常指的是開發或測試團隊在網站或 APP 上已經發現的問題，但可能因為優先級、資源有限、技術能力等等因素，造成這個問題暫時無法解決。
通常，known issue 都要經過產品經理或專案經理同意才能入列，畢竟這個責任由 PM 承擔。
要看出一個產品經理的程度，就要去看他會不會去問這個 Bug 的 root cause，以及後續他怎麼處理。
產品經理應該要知道的重點
- Bug 類別與優先級：產品經理需要了解不同類別的 Bug 及其影響，以便有效分配工程資源，在瞭解 Bug 的嚴重性、優先級之後，能幫助你決定哪些問題要優先處理，哪些可以延後。
- 用戶體驗與功能穩定性：即使是不常使用的功能 Bug，長期下來可能會影響用戶對 APP 或網站的信任度，產品經理需要持續監控產品的穩定性，優先處理影響用戶體驗的問題。
- 跨部門協作：處理 Bug 往往需要工程師、設計師、QA等多個部門的合作，產品經理需要清楚溝通 Bug 的影響和需求，確保修改過程順利進行。
- 數據支援決策：使用數據來支持判斷 Bug 的嚴重性，例如，錯誤發生的頻率、影響的用戶數量等，能幫助產品經理做出更精確的優先級決策等等。
- 用戶反饋與迭代：持續收集用戶反饋，有助於快速發現 Bug 並改進產品，產品經理和客服同仁應該建立反饋機制，讓用戶問題能夠被快速反映和解決。
- 風險管理：了解不同Bug的影響範圍，做好風險預估和應對策略，避免因Bug導致產品發布延誤或用戶流失。
以這些 Bug 判斷與對應方式，在我的「說人話的基礎技術課：聽懂工程師到底在說啥？」課程裡都有實戰練習，歡迎大家報名。