用 User Story 的方式寫 Bug Report（技術債的償還）

在 Agile 裡面，尤其是使用 Scrum 來進行開發的團隊，很常會用 User Story 來描述一個 feature，不但容易閱讀，也可以在不需要把所有細節都說完的狀況下讓開發者可以自動補完規格。因為 User Story 闡述的是一個「動機」，只要你明白一個人的動機，就很容易可以預測他的行為。

在寫 User Story 的時候，要注意重點是「User Value」，而不是規格，就好像你請一個工人搬運玻璃時，如果跟他說 「時速只能 1KM、上下樓梯要小心、不能用丟的」 ，不但容易困惑，也有很大機會還是摔破了。因為他雖然有做到很慢、很小心、不用丟的，但可能放在車上的時候沒有固定好就撞壞了。但如果你是說 「這個玻璃是主人的傳家之寶，絕對不能摔破，他女兒會心碎的」 的話，就更能讓人吸收這個指令，搬運的時候就會想盡辦法不摔破玻璃。越能夠站在使用者的角度思考，這個 User Story 就越是成功。

也就是說，「規格」是很容易用不同方式解讀的，就算 function map 寫的多詳細、wireframe 畫的多美，就算是用 Invisionapp 等工具直接做出可運作的 prototype，工程師解讀時，都還是有可能漏東西的。所以 User Story 才會如此重要，他傳達的是更上層的、更策略面的。（延伸閱讀：Scrum Team 必須遵守的 PRO 協作法則）

基本的 User Story 概念

今天這篇文章想討論的是 Bug 的 User Story 寫法。以 Scrum 的理論來說，User Story 必須是提供 User Value（使用者價值）的，但是 Bug 的修理，很多時候只是還債而已。還之前寫出垃圾的債、還之前趕時間硬兜的債、還之前沒想清楚的債。還債是很正常的事情，也是很有價值的，但很容易會被認為價值比較低，好像「使用者終於可以成功登入不會壞掉了」這樣的價值總是卑微的。但是 Bug 也不能不修，因為把壞東西修好，使用者才能繼續使用啊！而且當產品發展到一個地步，技術債的償還就是每天都在做的事情了。必須重視這件事情並且給予價值，尤其是越成熟、複雜的產品，老闆或產品主導者越需要有這樣的意識，不能認為 debug 是工程師在認錯，而是很有價值的一件事情。

先讓我們來複習一下 User Story 的基本公式：

• As a < type of user >, I want < some goal > so that < some reason >.
• As a < role of user >, I want < some feature > so that < some business value >.

換成中文，就是：

• 我是 < 某種類的使用者 >，我想要 < 做某些事情 > 以達成 < 某種目的 >。
• 我是 < 某種角色的使用者 >，我想要 < 這些功能 > 以達成 < 某些商業價值 >。

以下是範例：

「我是一個家長，我希望我的小孩一天上網的時間可以限制在兩小時以內，才有時間做功課並養成自制力的習慣。」

這樣的需求就很明確，由這個大方向繼續寫所有功能細項的 User Stories，軟體公司就可以開發一個上網計時的功能。（但限制小孩上網時間真的好嗎？）

User Story 寫法可參考這篇：
https://www.mountaingoatsoftware.com/agile/user-stories

Bug/技術債的 User Story 寫法

那為什麼要認真的為 bugs 寫 User Stories，不要就直接修掉就好呢？因為 有些 Bug ，在開發者眼裡，有可能是個 feature 啊！ 有時候真的是呢！

曾經有使用者回報說在 Lightbox 的狀態下點旁邊黑色的地方，Lightbox 就會關掉，對工程師來說這是很正常的一個 feature，也是 Lightbox 預設的行為模式。可是對使用者而言，在那個頁面的 Lightbox 有個表單，使用者可能輸入很多資料，卻不小心點到旁邊就關掉了，這個 feature 就會被認為是一個 bug，站在不同角度解讀同一樣東西，結果就會不一樣。

因此許多人開始討論 bug 相關的 User Story 如何寫。一般來說 User Story 是一種把需求極度簡化的格式，可能有 10 個 features，但都只有一個 intention/motivation。而在 Scrum 執行過程中，一般除了 User Story 還會制定 Acceptance Criteria，也就「說這個功能所必須包含的最低細節、或是要達成這些部分」。這是很重要的一個環節。在測試過程中，必須時時刻刻想著每一個功能的細節是不是有符合原先的 User Story 以及是否有完成 Accpetance Criteria 列出的項目。

所以在一個 Sprint 裡面，所謂的 bugs 可能有兩種：

1. 是目前 Sprint 裡面，某一個 User Story 實作之後產生的 Bug：這種狀況可以直接解，不需要寫 User Story。依照原本的 Acceptance Criteria 即可。這種 debug 除非當初估算錯誤，不然不會另外計算點數，會包含在原本估算的點數裡面。

2. 比較獨立、重大的 Bug：如果一個 bug 大到要在 Sprint Meeting 討論，並且做分工、重新分配點數，那就有價值寫成 User Story。

這時建議用以下的公式。這個公式是參考 GWT 的公式，原本是用來寫 Acceptance Test 的規格。

複習一下 GWT 公式：
(Given) some context
(When) some action is carried out
(Then) a particular set of observable consequences should obtain

Bug 專用 User Story：
在某種狀況下（操作某個環節），
當執行某個行為，
發生了什麼事情，但應該要發生的是另一件事情。

越能夠流暢的說「什麼狀況」、「做了什麼事情」，這個 User Story 就越成功。雖然這邊沒有強調是「誰」在操作，但還是要帶到，因為這是「操作脈絡（Context）」很重要的一環。另外有一個很重要的，就是在 User Story 裡面不能只說「這樣之後就壞掉了」，必須要有「你認為正確的樣子」。就算壞掉是個頁面變成白畫面，很明顯就是壞掉，也不能說「我點了按鈕就變成白畫面了」，必須要說「我點了按鈕變成白畫面，應該要能顯示內容才對」。因為很多時候你認為的 bug，對工程師來說是 feature，你必須清楚的說明你認為的 feature 是長怎樣，不然搞不好「白畫面」才是正確的也說不定呢！

錯誤示範：

• 參賽者進入比賽網站想要報名，他點報名按鈕，並且登入後，頁面跳到其他頁面去了，他不知道怎麼回到要參加的比賽頁面。
• 有一天，主辦單位發現當參賽者第一次在佈告留言時，可以收得到Email通知，但當參賽者第二次回覆留言在第一則留言下面時，就收不到通知了。
• 點選酒館小報，進入後點擊下面的頁數，不論點第2頁或第9頁，畫面都還是在第一頁。

正確的 bug report 專用 User Story，要加入「應該」怎麼樣：

• 參賽者進入比賽網站想要報名，他點報名按鈕，並且登入後，頁面跳到其他頁面去了，他不知道怎麼回到要參加的比賽頁面。登入後，應該要能夠回到原本報名的頁面才對。
• 有一天，主辦單位發現當參賽者第一次在佈告留言時，可以收得到Email通知，但當參賽者第二次回覆留言在第一則留言下面時，就收不到通知了。應該每次留言都會收到通知。
• 點選酒館小報，進入後點擊下面的頁數，不論點第2頁或第9頁，畫面都還是在第一頁，應該要跳到下一頁。

除了加入「應該」這兩個字，有時候也可以加入「希望不要」這種表達方式。比如說：

• 參賽者進入比賽網站想要報名，他點報名按鈕，並且登入後，希望不要跳到其他頁面，而能夠跳回報名頁面。

如何重現 Bugs？

很多時候測試人員或是使用者提出 Bugs 之後，工程師會說「在我的電腦不會耶！」這時候會把這個 Bug 存在的色彩降低很多，也會把這個問題變成很模糊。因此除了提出 User Story 之外，如果這個 Bug 稍微比較複雜，非常建議列出重現的步驟。

像這樣：

1. 進入網址 http://xxx
2. 點「報名」，跳出登入框
3. 登入後，目前是跳到首頁，希望能夠跳回報名頁面

這樣一來，無論是誰執行這樣的步驟，理論上都要能夠重現問題。當然有些問題就是很難重現，可能和使用者電腦、瀏覽器、快取、天時地利人和有關，那問題就真的比較深，要重現一個問題比較需要資深的 QA 來做，就不在這篇文章的討論範圍了。

最後，什麼狀況需要寫 User Story 呢？當你覺得有價值的時候，說穿了這就是一種溝通方式，讓我們這些麻瓜們，能夠和工程師溝通。User Story 理論上一定要能為使用者帶來價值，才有存在的意義。所以無論你在產品團隊擔任什麼角色，只要站在使用者的立場，就不會錯啦！

• 本篇主圖是獎金獵人 Scrum Team 這次 Sprint 的一小角落。我們用 Asana，下次介紹！

延伸閱讀

• How to Write User Stories for Bugs
• Writing Better User Stories and Bug Tickets