什麼是好用的缺陷報告記錄
當資訊不明確時,意味著資訊傳匯出現問題,失真或者通道斷裂。
TD的最根本的使用者是開發人員,他們據此處理程式中發現的問題。
開發人員處理問題時需要關心的資訊應該在缺陷報告記錄中體現:
。讓開發人員快速理解問題的資訊:眾多功能和用例中的哪一個
---什麼功能出的錯
。讓開發人員能瞭解或想象到捕獲此問題時的場景:開發人員能夠在除錯環境下還原或者能夠進行程式碼邏輯分析
---具體的操作步驟,甚至驅動資料,系統環境(這個不常需要)
。誰報告的:
知道具體的報告者,在上述資訊不明確的情況下,開發人員可以知道找誰詢問。
誰能決定Assigned To?
。測試人員並不一定知道(甚至通常不知道)該分配給誰
分配給誰需要一定的專案開發資訊,功能的開發者,如果涉及多個模組和多個開發者,則不容易分辨出來。那相當於測試人員在診斷問題了。
專業的測試人員相對可能比較容易決定,與開發更接近,但參與測試的客服人員則無法決定。
在不清楚分配給誰的情況下,分配給專案經理(具體的人或者建立一個抽象帳戶)
最近發現TD報告經常不符合上面基本的預期。
---Detected By:很多是admin. (是測試人員沒有自己的帳戶嗎?)
---描述過於簡單:開發人員需要憑藉聯想才能估計到問題所指
原因可能有:
。沒有要求
。沒有培訓
。個人工作習慣:報告可能來自個人工作的記錄,直接貼上到TD的
。規格化操作可能更費時:嫌慢
以下是2個示例:
1.bug1280
Summary:基本屬性
Details:
1:顯示資訊不完整排程引數下面的解釋說明沒有完全顯示
。基本屬性?是哪個模組的功能,操作導航呢?
。配上截圖更一目瞭然
2.bug1279
Summary:資料字典→修改屬性
Detials:
1、修改屬性後資料庫中屬性無法更改、例如:在介面中修改tb_10028_1117表中的dest_mis_id欄位的長度及欄位名稱,在TB_1031中的長度發生變化,對應TB_10028_1117中的欄位長度未發生變化,修改dest_mis_id為dest_mis_id_1在表TB_0044中的名字仍為dest_mis_id,更改屬性後需重新開啟後,在其他規則中才能看到有更改
。如果能把Details的內容精簡到Summary,並且提供更多的資訊,似乎考驗我們的歸納能力了
Summary該是什麼樣子的?
---介面配置工具資料字典維護,修改屬性不起作用
(沒有絕對的指標,參考指標是:更多的重要資訊,準確)
。我猜測這是客服人員報告的:內容非常淳樸,以一個純粹的使用者的角度:他能簡單地告訴你做的根本不對。如果以這種目標審視我們的程式,並最終符合,則程式會比較完美。
----------------------------------------------------------
這是我的回覆:(我的習慣是直接在Description中回覆處理描述)
字典資訊維護的基本邏輯應該是:從現有物件獲取,而非孤立指定。
說明這種編輯式的操作是錯誤的。(缺少先期定義)
在已開啟規則配置的情況下,使資料字典的變化即時生效,需要不那麼容易的程式實現(事件響應,規則的編輯狀態控制)。
----從軟體完美的角度,確實應該這樣。
(退而其次,提示一下使用者,資料字典更新只有在重新啟動程式後才生效)
理論上,除非不得已,你才需要重新啟動程式,有時重新啟動是簡化實現的手段。---但可能惹使用者抱怨。