一、介紹
這是一篇英文的文獻，昨天把他翻譯出來了。覺得還是比較有用，所以決定在這里把它貼出來。原文在：
http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILBROWSE&ObjectType=ART&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10
二、摘要
面向交付的項目管理和測試驅動開發能夠結合在一起，能夠為客戶、開發成員和管理者提供客觀的更容易理解的方法來測量項目的進度。在這篇文章里，john ferguson smart提供了一個學習用例來說明如何通過這種途徑進行工作。
三、名詞解析（自己添加的）
3.1 面向交付的項目管理是一種項目管理方法，測試驅動開發是一種開發方法。
3.2 面向交付的項目管理：就是本文說的，把任務分下去，總體任務代表一個總的交付，然后各個子任務代表子交付。項目根據各個交付任務來進行管理。
3.3 迭代的開發方法：就是先完成部分主要的功能，形成一個版本。然后再逐漸添加新的功能，形成新的版本。
3.4 測試用例（test case）：可以理解為就是測試用的程序和方法。每個測試用例對程序的某個功能進行測試，看是否實現了這個功能，有沒有bug。完備的測試用例就是對程序的各個功能和穩定性進行全面的測試。設計好的測試用例，才能全面而且盡可能快的完成程序的測試。
3.5 測試驅動開發：表示總的程序需要什么功能，各個子模塊需要什么功能。指定好測試用例，程序完成了測試用例的功能，就表示開發完成了。將測試用例用于開發過程中，而不是說先把程序寫好了，最后再測試。
3.6 可交付性（deliverable）：可以理解為可以交付的工作產品，就是具備獨立功能的一段代碼。
3.7 beta版本：beta版本就是軟件開發的一個階段，一般這個階段，程序已經可以完成大部分的功能，也比較穩定了。一般beta版本開發出來以后，就會提供給用戶或者內部人員免費使用，然后根據使用發現的bug，進行修正。
四、可交付性的定義
所有的工程項目，原則上都具有可交付性。如果采用迭代的開發途徑，為了制定一個迭代的、基于里程碑節點的交付方案，需要將主交付性可以分成多個小的子交付性。（比如一個應用程序可以分成多個模塊、函數或者用戶開發實現）。
五、WBS和項目計劃
工作分解結構（WBS）是一個大家熟悉的而且非常有用的工具，用來將一個項目分解成容易管理的（也有人說可以消化的，或者可以咀嚼的）多個任務。在一定程度上，你分配WBS任務給單獨的開發組成員，（某些時候，是一小群開發成員），然后要求他們產生一個具體的可交付產品。
工作分解結構（WBS）往往是跟項目計劃緊密相連。這里，對于工作分解結構（WBS），工作需要細化到每個任務對應一個可交付性的條款，然后分配到具體的小組成員。將具體的交付工作分給具體的小組成員，可以讓開發者將開發活動上聚焦在具體的、短期的目標上，同時也可以培養開發者的buy-in能力和責任感。
六、測試用例
自然，我們也為每個交付要寫一組測試用例。這些測試用例代表了每個模塊可以被接受的標準。可以有很多方法來做測試計劃和測試用例。大部分會包含某種形式的，一系列的執行動作和步驟，伴隨著特定的結果。在我們的用例中，對于每一個可交付的模塊，我們將對應的測試用例填到Excel電子表格中，并加注額外的信息以便容易使用。下面就是Excel表格的表項。
● 一個獨一無二的測試用例號
● 顯示ID
● 顯示區域
● 執行的動作
● 期望的結果
● 得到的結果
→ 結果：通過，失敗，還沒有測試
→ 描述任何非期望的行為
→ 相關的缺陷追蹤問題
根據我們的經驗，一組好的測試用例能夠很完美的指示產品是否準備好交付。理想的情況，是測試用例和產品的功能定義一同交給開發者，盡管在實際中，測試用例一般要晚一點點。分析文檔和測試用例為每一個模塊提供了具體的有形的目標，使得開發者能夠關注于代碼的編寫。
七、用測試來衡量進度
7.1 衡量測試結果
基于測試的進度報告能夠用一種容易理解的、客觀的觀點來審視項目進度。在我們的項目中，對每個模塊需要報告下面的測試狀態：
● 全部的測試用例
● 通過的測試
● 失敗的測試
● 還未進行的測試
我們從下面三個主要方面來進行度量：
● 一個模塊當所有的測試用例都由QA執行過，并測試成功，這個模塊就算完成了。QA包括內部測試組和用戶測試人員。
● 測試一個模塊需要的測試用例的數目反映了模塊的復雜度。雖然不總是這樣，但常常如此。
● 開發是迭代的：新版本被頻繁的交付，測試也需要不停的進行，而不是僅僅在項目的最后才進行測試。
在這些條件下，各個模塊的全部進度都可以通過各個模塊的測試用例通過的數目來衡量。如果你能可靠的在特定的時間點（里程碑節點），獲得各個模塊通過的測試用例數、失敗的測試用例數和未測試的用例數，就可以把它制成如圖一所示的表格。
圖一：測試狀態表
7.2 模塊進度狀態
我從不相信一個開發者說他的一個模塊快要完成了。在我的書中，只有所有的測試用例都通過了，一個模塊才算完成了。然而，有些被普遍接受的原則認為，如果一個程序，85%的測試用例通過了，就可以進行beta版測試了。盡管你理論上認為必須100%的測試用例通過，才能說產品準備好了，但是我們的用戶通常會接受產品，盡管產品還存在一些不嚴重的問題，并且這些問題在將來能夠被修補。因此，我們把模塊的“預產品”狀態定義為至少95%的測試用例通過并且沒有嚴重的問題。最后，我把模塊開發過程的階段劃分原則制定出來。
我們劃分成五個狀態來表示五個開發階段，通過測試成功的測試用例的數目來客觀的衡量。
● 計劃階段：還沒有開始編碼
● 開發階段：開始編碼
● beta版本階段：85%測試用例通過。
● 預產品階段：95%的測試用例通過，沒有發現嚴重的問題
● 產品準備好階段：100%的測試用例通過
一旦你有了測試用例通過的百分數，你就對模塊的開發進度和穩定性有了一個很好的評價。我們將這些數據用圖形來表示，寫在每周的進度報告中。
可以將進度表示成紫色的條圖，用來指示模塊的工作進展。這能夠鼓勵開發者自發主動的清楚工作的進度。如圖2所示。
圖2 進度顏色條碼圖
八、基于測試的進度總覽
我們從更高的層次上，通過測試用過的數據來看項目的進度。如圖四所示。這圖對外行人很容易看懂，在項目的進展報告中，放在在執行總結情況這部分特別有用。
圖3 基于測試的項目進展總覽圖
九、缺陷數據
我們使用的迭代的開發周期，提供了方便的追蹤缺陷數據的基礎。（譯者注：因為迭代是周期性的提交版本，可以周期性的對每個版本測試，發現版本的缺陷）。我們一般一到兩周會提交一個面向用戶交付的版本，每周或者幾天就會提交一個內部版本。新版本的整潔性比增加的模塊數目或者修正的bug數目更重要。然而，QA人員在接受一個新版本之前，必須對上一個版本進行一個合理長的時間測試。交付的日期就必須一起商量決定。在期望的交付日期前，我們要考慮交付是否可行（能否修正嚴重的問題），要考慮哪些新模塊以及哪些bug能夠對用戶聲明。
為了實現這個，我們把缺陷數據放在缺陷數據庫，從數據庫中提取出缺陷數據來衡量產品的質量可可靠性。全局缺陷狀態圖表示了各個缺陷狀態（open, to-be-deployed,pending validation等）的缺陷數目。
我們對每次交付，都要衡量缺陷的狀態——記錄公開的問題數目和總的問題數。這對于交付規劃是非常重要的。
十、歷史數據
對于跟蹤隨時間變化的測試的結果也是很重要。它能告訴你軟件的可交付性和穩定性的速度（多長時間可以產生一個交付版本，多長時間可以達到某種穩定程度）。如圖6和圖7所示。
圖6 歷史數據：隨時間的測試完整性
圖7 歷史數據：隨時間的測試完整性
十一、這個方法不能做的
（譯者注：這個方法指基于測試的項目進度管理）
這種方法不完備，也不是要取代傳統的項目進度跟蹤和匯報。這種方法的特別之處在于它是純粹面向交付的。因此它能夠幸運的忽略哪些諸如延時、開銷、資源消耗、關鍵途徑等等術語。這些術語能夠而且應該被諸如Gantt圖，PERT圖等代替。實際上，這種方法能夠給上層管理人員、小組成員和項目投資人等一個項目進度的直觀表示方法。基于測試的交付狀態是一個重要的而且容易理解的項目匯報方式。但是延遲、花費和面向任務的觀點同樣重要。
十二、對這種方法的評價（自己添加的評論）
測試用例的設計非常重要，要完備，系統。要有機制對測試用例的優先級進行設定，哪些優先級高，先實現；哪些沒那么重要，后實現。 對各個測試用例要歸屬各個版本，哪個版本應該實現哪些測試用例。要設計好。