由於自己是從 Mozilla 開始接觸相關事務的，很多習慣大致都由在 Mozilla 的生活養成。簡要分享自己回報軟體問題的步驟。
關鍵問題：「在什麼樣的情境下，引發了與預期有所出入的結果？」
1. 情境
- 作業系統、搭配軟體等
- 誘發錯誤結果的步驟，術語稱之為 reproduce steps，這會需要回報者自己多試幾次確定步驟正確。寫作上的重點是儘量用很難操作錯誤的表達方式，例如「開啟新分頁」或許不如「按下 Cmd/Ctrl - T，開啟新分頁」 -- 或許，其他開啟新分頁的方法本來就不會引發一樣的錯誤。
2. 預期
- 本來應該發生什麼事的描述，其實不會很難寫。
- 如果有其他可以供參考的資料，例如別的同類軟體產生的正確結果截圖等，則又更佳。
3. 結果
- 做完上述步驟後，實際發生的結果
- 有畫面截圖或者其它可證明/說明結果的報表（例如 log 檔），則又更佳。
其他
- 出現機率：有些事情可能不是每次都會出現，但出現機率高到讓你覺得不容忽視。這時可註記之，一方面這是重要資訊，很可能代表還有隱藏的線索尚未發現；二方面，也是要避免看這份回報的人自己試一次沒問題就打回票了。
- 標題簡要清楚：這跟寫信一樣，就不多提。
由於 Mozilla 的 Bugzilla 平常需要應付很多新手回報問題，所以上面的要點已經被做成了制式表單（如圖，我另外標了數字可對照之），另外也有一篇文章教使用者如何回報問題，可參考之。（雖然看不懂那篇英文的人，或許也無法獨立、不需協助地回報問題，但有人想翻譯還是大歡迎的。）
所以我自己的慣用格式如下：
## Steps:
1. reproduce
2. steps
3. here
## Expect
(expectation after the steps above)
## Result
(actual result)
## Notes
(other notes)其他事項會列在 Notes 處，而有時自我判斷無關作業系統與搭配軟體版本的就省略之（有時會判斷錯就是，屆時還是得花上一次來回）。因著「簡要分享」的想法，有些例如「重要性」什麼的就且不提。比我能寫得好的大有人在，只是分享一下習慣。
沒有留言:
張貼留言
歡迎留下您的意見