正交缺陷分類（ODC）流程簡介及應用

校驗小組成員間如何更有效的溝通？

校驗小組成員通常會從測試和開發人員中分別挑選。在很多大項目中，測試和開發團隊可能并不在一個地區，甚至存在時差。如何增強跨地區小組成員的交流，使得資源共享、溝通及時無誤呢？這就需要有一個信息共享平臺。從我們的實際經驗中來看，wiki 是一個不錯的選擇。wiki 是一種多人協作的寫作工具，每個人都可以在上面發表意見。下面是作者正在參與的一個項目組所采用的 ODC 校驗小組 wiki 上的內容，包括如下方面。

• 目的：明確校驗工作的目的；
• 校驗小組人員名單：包括姓名和聯系方式；
• 校驗流程說明：針對本項目的特點，制定出適合本項目的校驗流程。以作者參與的項目為例，校驗流程可以包括：
  • 每周一，由 ODC 校驗小組負責人分配給每個人這周需要校驗的缺陷（分配的方式，會在下面的“每周工作安排”中提到）；
  • 校驗小組中的每位成員開始逐一校驗分配給自己的缺陷。如果發現該缺陷的 ODC 屬性有填寫不正確的或忘記填的，就需要馬上發郵件給該缺陷的發現者或解決者，予以修改。若缺陷本身的描述信息足以令校驗員分析出正確的選項，那么在郵件中需要寫明校驗員的修改意見及原因。若缺陷的描述信息不清晰以至于校驗員無法作出準確判斷的，也需要在郵件中指明。待測試或開發人員在缺陷中補充了更詳細的信息，校驗員再重新進行校驗。
  • 一旦校驗完成，校驗員需要在缺陷管理工具中對該缺陷進行標識，如前面我們提到的“ODC 是否已被校驗”屬性項，這時把它的值從默認值“否”修改為“是”。以表明該缺陷已被校驗過。校驗組長下次再分配待校驗的缺陷時，就會把已被校驗過的缺陷過濾掉。
  • 校驗員把在校驗過程中發現的問題，例如錯誤分類趨勢等進行反饋；
• 每周工作安排：
  • 可由如下表格進行工作分配和進展跟蹤。其中的前兩列由 ODC 校驗小組負責人在分配工作時填寫。后兩列由 ODC 校驗員在進行校驗工作時填寫。表 1 列出了一些可能出現的情況。

表 1. ODC 校驗工作分配 / 跟蹤表

表中的第三列“是否已被校驗”與缺陷管理工具中的“ODC 是否已被校驗”屬性項相對應，同樣有四個選項可供選擇：不填表示校驗人員還沒有開始對該缺陷進行校驗；“是”表示該缺陷已經被校驗完成，可以作為評估階段的統計數據；“否”表示該缺陷還處在校驗過程中，等待相關人員根據檢驗員指出的修改意見在缺陷管理工具中進行修改。在校驗員發出第一封郵件后的三天之內，若沒有得到相關人員的響應，校驗員需要發送第二封郵件，同時抄送相關人員的直接經理。以此督促相關人員盡快更改 ODC 屬性，以便該缺陷被標識為“已校驗”；“N/A”表示該缺陷為無效缺陷。

• 會議紀要：記錄、傳達每次例會的情況，便于日后查看和跟蹤。下面以作者參與的項目為例，會議紀要內容包括如下方面：
  • 參會人員：參會人員名單。
  • 公告：通常是上次會議待解決事情的進展或結果的說明。也可是重要的通知。
  • 本次會議討論內容：本次會議討論內容詳情。
  • 行動：
    • 根據會議討論的結果，有些是需要在會后付諸于行動的。這樣就需要把每個行動的內容和負責人記錄下來，以便下次會議進行跟蹤確認。下面舉例說明。如果本次會議記錄了如下兩條行動：
      • 某某去聯系缺陷管理工具的管理員，添加一個額外的屬性來記錄缺陷是否已被校驗過；
      • 某某去邀請 ODC 專家 David 來參與我們每周的例會，幫助我們解答校驗過程中遇到的問題。
      在下次會議開始的時候，首先要確認上次會議中這兩條行動是否已經實施。并把進度或結果在本次會議紀要中的公告部分進行說明。
• 參考資料的鏈接：
  • 關于 ODC 校驗工作和 ODC 分類說明的參考資料鏈接。

對于校驗小組長來說，如何更有效、更直接的分配校驗任務？

僅僅在 wiki 中列出工作分配表，雖然也可以進行任務分配和進度跟蹤，但由于并沒有跟缺陷管理工具相關聯，所以需要校驗人員根據表 1 中的缺陷編號，逐一在缺陷管理工具中進行查找。顯然這樣很浪費時間，也難免會在查找過程中發生錯誤。因此在缺陷管理工具中直接分配任務是更合適的辦法，同時利用表 1 中所示的 ODC 校驗工作分配 / 跟蹤表進行進度跟蹤。

在作者從事的項目中，我們采用在缺陷管理工具中增加一個名為 ODC Validator 的屬性，如圖 4 中所示。來供校驗小組長在分配任務時進行選擇。這樣校驗人員在登錄缺陷管理工具后，直接查詢 ODC Validator 屬性為自己名字的缺陷列表即可。

圖 4. ODC Responder 選項簽中新增加屬性 ODC Validator:

文章來源于領測軟件測試網 http://www.kjueaiud.com/