如何有效的回報問題 (How to Report Problems Effectively)

整理前一個工作做教育訓練的資料，本來對象是給 SQA (Software QA) Team 的教育訓練，後來發現這個題目，所有人都要會，也就是 如何有效的回報問題。

所有人 指的是：團隊裡的每一個人。實務上很難，所以要一起討論、學習。以測試角度來看，就是 如何有效的回報 Defect / Bug，底下的截圖是以前教育訓練的資料，隨著時間的演進，現在看起來還是有一些參考價值吧？

文中用 Issue 統稱 Defect、Bug 這些 議題。更多參閱 Issue Tracking in Redmine

20230523 更新: 本文部分收錄在共同著作《軟體測試實務》第一冊第五章之中，歡迎大家彭場指導。

如何描述問題

如何把問題講清楚，讓處理問題的人、判斷問題的人可以快速明白問題的本質，這是描述問題的目的。描述問題有以下三個重要的原則：

清楚的症狀 (Symptom)、現象 (Appearance)：用來判斷是否不正常的表象與特徵
可靠的復現步驟 (Repeatable)：發現並確認問題重要的資訊，也是測試過程中最花費時間的，理想的步驟是 有序性 (Ordered)。
有價值的資訊：參考資訊、包含環境、系統 log、產品規格、story 等。

基於這些描述方法，後來我延伸出方法論，參見如何意識到問題的存在

如何有效的錯誤報告

這張圖主要參考自 Simon Tatham 的文章: How to Report Bugs Effectively

以測試角度來看，使用 Template 的目的：

可以有效的重現 (reproduce) 現象，確認是不是 問題
可以加速溝通的效率，同時已經有相關的參考資訊

底下是我過去團隊用的 Template，主要用在功能性驗證:

## Precondition -- optional
Precondition for this issue.

## How to reprocedure the problem

1. install APP form AppStore
2. open app with 886929168168/12345678
3. goto video view, and click the active device
4. ..

## Expected result

The video should be transferred immediately.

## Actual Result

The exception occurs.

## Log _optional_

put server, app or device log to here


## Environment

- Phone: iPhone5, iOS 7.0.2
- server version: server_2.3.0_b20130116-1200_r23765.tar.gz

## Spec- _optional_

[[Wiki Title Here]]

這個樣板包含這些項目：

Precondition: 問題的前提條件，例如 iOS 9 以上
How to reprocedure the problem: 如何重現這個問題
- 通常是 有序性 (ordered)，重現步驟如果是無序性的，那 ….
- 復現問題的關鍵, QA 程度可以從這裡看得出來，好的 Bug 走一次就可以重現
- 很複雜的問題，可以直接錄影，如果有 remote site
Expected result: 預期結果
- 資料正確性
- 邏輯性
- 畫面
Actual result:
- 實際測試時的結果
- 複雜的問題可配合圖、影音等方式呈現
Log (optional): Server, App or Device 的 Log
- QA 如果可以看 Log，問題的回報會更精準，更有說服力
Environment: 測試的環境，包含測試出來的版本資訊、Build 資訊
- 像是問題發生在哪一個版本，詳細參閱 Version Control，如果貴公司的軟體沒有版本，請好好規劃這件事情。
- 建議要有時間點，或者 commit code，像是 git hash or svn number.
Spec: 商業需求的來源
- 為什麼個現象是 Issue 的依據來源

要特別強調在描述問題的過程：代名詞要注意，主、動、賓 不清楚是中文語言特性，因為習慣省略主詞或者受詞，引此常常造成溝通認知差異的問題。

另外幾點文中沒有說，但我會強調的，描述清單的 次序性：

ordered list (有次序性)
non-order llist (無次序性)

問題的重現 (re-produce) 通常是 有序性 的，而現象，通常會是 無序性 的。有時候也會反過來，所以 QA 再回報問題的時候，要很清楚知道，問題的次序性是什麼。

這常寫 Markdown 的人應該會 (要) 很清楚。

回報問題的案例

案例一：iPad 問題 (Updated: 2018/08/04)

這事情發生在 2018/08/04，剛好跟這篇有關係，我就做了個例子。

我一早就被 iOS (疑似, iPad Only) 的 Bug 吵醒，釐清了一些狀況，錄了這段，按照本文回報問題的方式，整理了以下問題的回報範本：

## Environment

- iOS 11.4.1
- iPad Air 128Gb.

## How to reproduce?

1. connect the power adapter to iPad
2. open Click app, tap Timer, set a countdown in 5s
3. start the countdown
4-1: stop the sound by tab Home button,
4-2: stop the sound by swiping up notification

## Expected Result

Sound should be stopped.

## Acturl Result

Sound keeps playbacking, unstoppable.

## Notes
- Remove power adapter to fix the issue.
- No issue on iPhone6

這段回報的目的就是讓收到 report 的人 (不管是開發、還是 PM)，可以依照步驟把問題的 現象 重現出來，之後才有辦法判斷問題的 嚴重性。

最後錄了一段畫面，讓溝通可以更直白：

這個問題現象，從我的錄影實驗中可以知道，問題是 Click 跟 充電 似乎有關係，但是一般整合測試怎麼會想到這兩個有關係？這問題就跟從 iOS 無限黑屏事件，談軟體測試階段 - 回歸測試 Regression Test 描述的想法一樣，要在開發過程 發現 這個問題，其實是不容易的。

這邊的開發過程指的是 Release 之前。

案例二：Positive Grid Spark 40 (Updated: 20230422)

這個案例是我的吉他音箱 Positive Grid 的 Spark 40 突然沒聲音，底下是我回報問題時的錄影：

底下我用虛擬碼的方式描述症狀：

The pseudo code of symptom:

PowerOn(); // a few moment, maybe 1hour, 30min, or 5m ... etc.
for(;;) {
   Abnormal();  // about 40s
  Normal();     // about 1min;
}
----

開機一段時間後;
for(;;) {
   不正常, 40s - 充電 (我猜的);
  正常, 1min ;
}

這次 RMA 的結果，是 PG 的客服換一台新的機器給我～

提問的智慧

同樣的這張 Slide 主要參考自: How To Ask Questions The Smart Way by Eric Steven Raymond

先強調的是: 標題很重要，Issue 的標題要有相關 關鍵字、現象、嚴重性 … 等，掌握這三個原則，一眼就能抓到問題，例如：

iOS 無法正確讀取商品頁
Android 點選 Push 後發生 Crash
Firefox 無法正確顯示 Live Streaming 影像、緩慢

另外，提問題之前要做的，最好能夠：讀過手冊 / 設計文件、了解產品，避免開出無效的 Issue，浪費彼此的時間。

我在導入新技術之前，一定會做這樣的功課：把整本手冊讀過 幾次，AWS 的學習基本精神就是這樣。像是：

所以提問題之前，要問問自己，對於產品了解多少，對需求深入多少。

輕重緩急

時間管理的兩個軸是：重要性、優先權。當時我用在處理 Defect 的差異，也是兩個象限：優先權、嚴重性。

這裡有些特例是問題很嚴重，但是優先權很低。

像是那時候做 IoT 產品常出現的嚴重問題就是 Video Streaming Delay 很嚴重，但因為是走 Mobile Network，所以常常有 case 是使用者在深山裡，網路很慢，造成產品無法使用，但是實務上，急不得，因為急也沒用 XDD

品質？

如何回報問題 這件事情當作是品質之一，換言之，如果回報問題的程序本身沒有品質，那麼這個產出是沒意義的。

品質不是測試，而是整個開發過程。

釐清問題，本身就是個品質。回報的目的在於：

1) 問題的症狀
2) 蒐集復現的路徑
3) 蒐集問題的資訊

讓收到回報的人，可以快速確認問題的：

1) root cause (Dev)
2) 判斷嚴重性 (PM/PO)
3) 優先權 (PM/PO)。

修復問題後，可以依照此報告，有效率、精準的驗證。

有效地描述問題 (Updated: 2019/11/16)

一直以來，怎樣描述一個問題 本身就是個問題。常常會因為無法有效地描述問題，造成誤判，或者額外的溝通成本。

描述問題常用的情境：

系統線上問題的回報 (客戶 to 公司)
系統緊急異常
團隊之間協作時，遇到問題時的回報 (團隊 to 團隊)
團隊與 PO / 主管之間的問題回報 (團隊 to PO / 管理者)
測試與開發之間的問題溝通
… 還可以列很多

以線上問題來說，當發生問題，如果大家針對問題麼描述有標準化，那麼負責的團隊，就可以很快的搜集有意義的資訊，做有效的判斷，最後下決策，才有辦法找到 root cause，對症下藥。這個過程其實跟資料處理概念一樣，先蒐集有意義的資訊，然後分析、處理、最後決策。當問題描述不清楚，沒有有效的方法時，往往就是溝通成本、爭議、衝突的來源，特別是處理線上緊急異常時。

這幾年 如何問問題 變成很重要的課題，不管是管理，還是團隊之間的協作。除了如何問問題之外，我覺得 如何描述一個問題 也是很重要的。

如何有效的回報問題 (How to Report Problems Effectively)

如何描述問題

如何有效的錯誤報告

回報問題的案例

案例一：iPad 問題 (Updated: 2018/08/04)

案例二：Positive Grid Spark 40 (Updated: 20230422)

提問的智慧

輕重緩急

品質？

有效地描述問題 (Updated: 2019/11/16)

延伸閱讀

站內延伸

參考資料

異動紀錄

Comments

About

著作

演講

Facebook

AWS Certifications