我的測試之旅：（10）貢獻——開發項流程（Development Item Process）

開發項流程（Development Item Process）

當時的這個Scrum試點專案身負重任，其中之一就是要探索出在新型的敏捷模式下該使用何種的開 發流程，負責人就是當時的Linux部門經理，而我則撈到了負責測試部分流程的機會。整個試點專案的人員擴張速度不錯，4個人的團隊維持了好幾個迭代，陸續有人加入，新的測試人員在大概是第四個迭代的時候才補充進來，而後逐漸擴張到兩三個團隊。這樣的擴張速度對測試流程的確定來說非常好，一開始我可以只考慮自己的想法，不斷地嘗試摸索，可以很快地得到反饋然後改進；等到想法大致成形的時候，又可以專注於幫助其他成員理解流程和使用，驗證流程的易用性；等到人員更多的時候，就可以著重驗證流程的推廣複用性。

試點專案並非是全權負責新產品的開發，它其實是歸屬一個更大的專案、產品的，產品經理在芬蘭，芬蘭也還有一些團隊，兩地之間的團隊必須要合作，雖然杭州的專案享有流程等各方面的自由，但也必須考慮和芬蘭團隊現有模式流程協作的問題。流程中也要把這些細節都考慮進去。

我討厭浪費，討厭重複的資訊，也不喜歡把不同特點的資訊混淆在一起，而且流程要為人服務，它需要根據人在工作中的行為、活動特點來制定，而不是憑空想象，這是我在流程總結中所秉持的重要原則。因此，在流程中測試活動開展所需要的資訊，每一份資訊只應該存在於一個位置，其他地方全部應該通過連結或者引用使用這些資訊，而且測試和開發都會用到的資訊也適用此原則。資訊應該分為長期存在和短期存在兩種，可以看做是從讀、寫的角度進行區分：同一份資訊和被測物件相關，且在可預見的未來還會繼續被讀寫的話，看做是長期的型別；同一份資訊主要是階段性的，和特定的版本、時間點相關的，且在可預見的未來只會被讀取但不會被更新（寫）的，看做是短期的型別。兩類資訊或者以不同的文件進行維護，或者以不同的方式進行維護。

如下簡單表述一下當時所設計出來的流程，這個流程因為種種原因在試點專案結束後沒有被延續使用，但是大概是三四年後我已經成為敏捷教練的時候，意外得知它居然一直在別的產品線沿用至今（當時），其生命力可見一斑。我將側重描述其變化、改進之處，和以往流程相同的地方則不做介紹。

• 新流程的目標包括：推動開發和測試專家們的密切合作以提高軟體的質量；合理化以及簡化相關文件；減少文件數量，加強維護，以提高文件的質量；促進開發和測試人員之間的互相學習，以增加專案資源的靈活性；等等。
• 開發項是新提出的概念，將軟體的規格說明書撰寫、設計、實現和測試封裝在一起，作為最小的原子化產品元件（Component）。原子化的意思是保持開發項之間的互相依賴在可以做到的最低水平；移除或重排任何開發項的時候，對其他開發項不產生（或產生最小的）影響。
• 在迭代開始前，先有技術報告或者需求文件，由此而產生出開發項；然後是和以往的專案過程一樣的入口階段，確定專案日程並且生成相關的高階（High Level）文件。包括整合計劃文件、專案計劃文件、模組（Module）測試策略以及開發項測試計劃文件都在此時建立。
• 所有和開發項相關的測試活動都在Sprint內完成，這些測試被稱之為DIT（開發項測試），測試用例本身還是屬於以往的功能測試級別。但是開發項的測試計劃、測試執行、報告等一系列過程全部都要在一個Sprint中完成，測試用例的自動化比例並未做硬性規定，但當時我們的成果是100%自動化。
• 專案成員主要分為開發和測試兩類工程師，但是角色的定義並不是拿來當做不可逾越的紅線使用，必要的情況下，開發工程師也會承擔部分測試任務甚至整個人投入測試，或者測試工程師也會和開發工程師一起，結對開發程式碼。
• 開發人員的工作安排會受到測試工作的影響，每日站會或者平時工作中，可能會發現軟體不容易測試，就需要開發人員協助檢查以及修改程式碼提高軟體的可測性。或者是在開始寫測試指令碼之前，就去跟開發人員約定程式輸出的內容和格式。
• 測試文件根據資訊的長期性、短期性進行了區分。
  1. 測試計劃與報告：將這兩個單獨的文件合併到一起，在單獨的章節裡展示各自的資訊，每個軟體釋出使用一份測試計劃和報告。總共四個章節：被測功能描述以及模組列表（持續更新）、持續整合測試狀態（每個迭代的測試報告）、總結（質量評估、經驗反饋、推薦和建議）、現存問題（尚未解決或仍不明晰的問題）。目的是在單個軟體釋出週期內持續記錄測試的狀態，縮減不必要的文件量。
  2. 測試用例與缺陷：每一個模組或技術領域使用一份測試用例及缺陷文件。文件內容包括：該模組或技術領域的整體描述，測試用例列表及狀態，缺陷列表，測試輔助程式，操作命令。目的是提供一份可以全面瞭解被測模組或技術領域的文件，包括當前的所有功能、曾有的和現存的缺陷，以及如何使用操作命令和測試輔助程式進行測試。
  3. 測試用例清單：用Excel記錄所有的測試用例即可，資訊來自於現有的測試管理系統，包括測試用例的編號、已測過的最新軟體釋出、已測過的最新版本資訊、測試用例的版本、測試用例名稱、自動化的狀態。
  4. 缺陷清單：用Excel記錄所有的缺陷即可，資訊來自於現有的缺陷追蹤系統，包括缺陷的編號、標題、嚴重程度、缺陷單狀態、相關的測試用例以及版本。目的是提供一目瞭然的缺陷清單，可以知曉其歷史及現狀。
  5. Sprint缺陷清單：記錄在Sprint開發過程中發現的軟體缺陷，相當於輕量級的缺陷追蹤系統，無法當天修復的問題才會被記錄下來，而無法在當前Sprint中解決的問題則會被錄入缺陷追蹤系統，並且錄入前一個缺陷清單。

Linux程式設計培訓

為了幫助新人快速地融入專案，我們還承擔著開發一套培訓課程的任務。在Linux環境下進行開發的同時，我們需要總結經驗，有針對性地記錄所需要掌握的各方面知識，並且做成培訓材料，提供給加入團隊、專案的新手。我也參與其中有少量的貢獻。

檢視更多“我的測試之旅”文章
1. 起點——作為軟體開發人員
2. 轉變——作為專職測試人員
3. 同期——加入測試自動化小組
4. 並行——自動化迴歸測試
5. 難點——功能改進的測試
6. 跳轉——追逐新鮮事物的探險者
7. 啟程——Scrum中的測試工作者
8. 困難——沒有現成的測試工具
9. 行動——簡化測試文件和流程
10. 貢獻——開發項流程（Development Item Process）
11. 嘗試——Scrum Master
12. 機遇——測試自動化培訓師和教練
13. 轉型——敏捷教練

敬請關注 《大測大悟——測試的敏捷之道》開放出版過程

聯絡方式：
- 新浪微博
- 谷歌郵箱 kaverjody @gmail.com
- LinkedIn