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


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

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

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

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


如何描述問題

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

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

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

如何有效的錯誤報告

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

以測試角度來看,使用 Template 的目的:

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
## 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 吵醒,釐清了一些狀況,錄了這段,按照本文回報問題的方式,整理了以下問題的回報範本:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
## 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 突然沒聲音,底下是我回報問題時的錄影:

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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,對症下藥。這個過程其實跟資料處理概念一樣,先蒐集有意義的資訊,然後分析、處理、最後決策。當問題描述不清楚,沒有有效的方法時,往往就是溝通成本、爭議、衝突的來源,特別是處理線上緊急異常時。

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


延伸閱讀

站內延伸

參考資料

異動紀錄

  • 2023/04/22: 增加案例 Positive Grid Spark 40
  • 2019/11/16: 增加 如何有效地描述問題 一段。


Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲