測試經理和PM對TC進行Review：
敏捷測試流程總結：
在敏捷方法中，XP方法強調測試在整個項目開發過程中的重要性。針對敏捷開發方法的敏捷測試不同於以往針對傳統開發模式的測試,在敏捷團隊中,測試是整個項目組的“車頭燈”，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基於這些可靠的信息作出正確的決定。不僅是測試員要保證質量，而是整個項目組的每壹個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標,***同為達到項目的最終目標而努力。敏捷測試也需要高度叠代工作、頻繁得到客戶的反饋，需要動態調整測試計劃、測試的執行。並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計劃。
根據公司項目目前采用的敏捷開發模式，相應的敏捷測試建議采用以下流程：
1. 驗證需求和設計
需求和設計具體來說壹般包括：(1)由項目經理根據需求文本而編寫的功能設計文本(Functional Design Specification);(2)由開發人員根據功能文本而編寫的實施設計文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性.
在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第壹用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。要盡早的開始測試，不要等待到功能完全做好才開始。
產出物:測試需要提交評審結果文檔,可以讓測試更多的參與DB Design,框架的評審中來
2. 測試計劃，測試用例
2.1 編寫計劃、測試用例
在敏捷開發的過程中由於是根據每個user story來估算時間的。開發人員將對本次叠代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先級。
好處：
客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先級。
問題：
在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。
分析：
由於版本更新很快，任務的時間都是以小時來進行估算的。開發人員壹般會忽略掉開發以外的時間，比如開發中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。
舉個例子：
開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。於是開發人員給的估算時間是2天。開發階段實際的花費時間如下，每天花費開例會的時間。在例會中項目的其他成員需要技術上的支持。於是發費了3個小時進行幫助。在開發的過程中遇到了壹些沒有預見到的問題，結果解決問題花費了4個小時。(也許更多)。需要處理壹些公司突發性的事務等等。所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本XP相關的書上寫到，在時間估算上最好的時間是編碼時間的2-3倍。聽起來很嚇人，但是實際的過程中，的確需要這麽多的時間。
測試人員根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。測試的這兩個文本也要被項目經理和開發人員審核。
2.2 測試用例的審核
為使開發人員能參與到Test Case的Review中來，以保證TC的質量和可行性，確保測試工作的順利進行，讓開發人員迅速地了解測試的重點並給出相應的意見和建議，測試人員在出 TC的同時，應出壹份TC_Matrix(Test Case跟蹤矩陣)，其中註明TC已覆蓋了哪些Features，具體每個Features對應的TC的編號，這樣在測試經理和PM對TC進行 Review的時候，能夠對TC的覆蓋率壹目了然，對覆蓋率不足(如某個重點Feature的Test Case不夠)的地方能夠及時給出意見。
另外，在每天早上的Morning Meeting上，測試人員可以簡潔地講述壹下當天測試的重點部分，以及項目中存在哪些嚴重的bug，讓開發人員了解當天測試的重點是什麽，怎樣進行測試，並提出自己的意見和建議。這樣做加強了開發與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。
在叠代後期測試要抽時間更新test case。
3. 實施運行測試
在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發人員來完成的，接收測試是由客戶代表來完成。
由於我們客戶無法在現場，我們采取了，開發人員做單元測試，測試人員做驗證測試，最後由客戶進行接收測試。在每個版本發布給客戶之前必須由測試人員進行測試，發布版本之後由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下壹個發布完成。
單元測試在daily build版本給測試前，開發首先要做單元測試，提前告知軟件中的薄弱環節，幫助測試人員調整測試重點。Unit test
做單元測試的好處是可以提高版本質量，減輕測試的工作量，減少淺層次的bug的發生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面。
驗證測試測試人員的驗證測試從總體上說就是將上壹步設計的測試用例按計劃付諸實施的過程。這壹階段的測試必須在周密的計劃下進行。這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃***同推進。從測試的過程來看，測試執行的壹開始可以是針對部分功能的，之後可以逐步擴展。接著開始采用叠代的過程完成測試任務，即將測試任務劃分為多個周期，壹開始可以做些關鍵的功能性測試，可以對代碼中的可復用部分(組件，構件)做完整的測試。接著的叠代周期可以做邊緣化的功能測試和其他測試，最後的幾個叠代應該用於回歸測試，和關鍵的性能和穩定性測試。
3.1 每日提供bug趨勢
為方便衡量項目的進度，測試可每天測試完畢後提供測試的bug趨勢，即將每天新生成的Bug數和每天被解決的Bug數標成壹個趨勢圖表。壹般在項目的開始階段新生Bug數曲線會呈上升趨勢，到項目中後期被解決Bug數曲線會趨於上升，而新生Bug數曲線應下降，到項目最後，兩條曲線都趨向於零。PM會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目Bug，
對於每個版本的bug，開發都應該想想為什麽會出現這樣的問題，特別是很低級的bug，對於同類的bug，是否可以避免。
測試需要考慮:探索性測試用例的編寫
3.2 測試用例的維護
在執行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增壹些測試用例：壹是對於當初測試設計不周全的領域，二是對於外部的Bug(比如從Beta客戶報告來的)，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時(敏捷項目中功能設計的更改頻繁)，所涉及的測試用例也要相應地修改，使測試用例保持和現有的功能需求同步。
3.3 根據項目不斷補充Common Sense
在項目進行過程中，測試人員需要不斷積累經驗，不斷補充、完善各類目的Common Sense標準。例如，由CTTS項目總結出的Common Sense for USA標準，在以後的美國項目中要嚴格按照它來執行測試，保證以前出現過的失誤在以後的項目測試中不會再出現。在保證項目質量的同時，不斷積累新的經驗。
3.4 控制中間版本
為更好地保證軟件質量，規避風險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三壹定要提交壹個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到後期最緊急的時候去完成。以前的項目中出現過項目前期很輕松，到後期bug越來越多，開發人員和測試人員都異常忙碌，經常加班的情況。為減少後期工作量，規避風險，建議開發進行Daliy Build，或者按照完成壹個feature就進行壹次build，針對這個feature進行測試，這樣就可以有效避免後期bug越來越多的狀況發生，後期工作量也就會相應減少，項目的質量也會更有保證。
3.5 發布版本前編寫Release Note
在每次發布版本之前，測試人員要根據待發布的版本情況編寫Release Note，使客戶對發布的版本情況壹目了然。Release Note主要包括三方面的內容：Fixed，New Features，Known Problems。其中，Fixed部分寫明此版本修復了上個版本中存在的的哪些比較大的bug;New Features部分寫明此版本新增加了哪些功能;Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善;或者列出需求不太明確的地方，有待客戶給出明確答復意見，在下個版本中完成。
4. 需求管理
采用敏捷開發模式的項目中，客戶對於需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，壹定要作跟蹤，每次的需求變更都要有相應的歷史記錄，方便後期的管理和維護工作。可將每次的變更整理記錄到需求跟蹤文檔中，並使該文檔始終保持最新更新的狀態，與需求的變化保持同步。
問題：
客戶可能會在壹個功能點上來回修改他們的需求，也許開始需要某個功能，結果做完以後又覺得不好，於是讓去掉這個功能。後來又由於壹些原因，有需要加上。在整個過程中可能來回修改了很多次。那壹定要記錄下變更的內容和日期。可能後期客戶會覺得壹個功能怎麽會花那麽多的時間，不是以前很早就做過了嗎?這時這些記錄才是解決客戶疑慮的最好證明。說白了，是有證據證明我們做了很多的變更。大家可能覺得，怎麽會有這個問題。其實當壹個項目長達半年以上，也許大家的記憶力都不可靠了(:p)
建議：
目前采用的是vss工具，對每天的Email中提到的需求變更做壹次backup，文檔以當天收到Email的日期命名
5. 項目開發末期開展“bug大掃除”
在項目開發的末期，可以開展“bug大掃除”活動。劃出壹個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。註意以下要點：
(1)盡管這是壹個測試活動，但參與者並不僅限於測試人員。項目經理，開發人員甚至於高層管理人員都應參加，如同全民動員。目的是要集思廣益;(2)要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助於發現更多的Bug;(3)為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。(4)可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。