[原文發表在https://hespr.blogspot.jp/2009/03/blog-post.html 寫在2009年3月
最近發現被人盜版了多處, 重新發布在CSDN]
最近讀了《我和敏捷團隊的五個約定》（from InfoQ），很是贊同，但是那些約定不少本來就來自於傳統方法，似乎並沒有體現敏捷團隊的特點。
在敏捷開發的測試方面有沒有不一樣於傳統開發測試的並且是有效的實踐？
從敏捷團隊的組建上來說，敏捷團隊並沒有要求安排專門的測試人員，甚至於在某些的方法中不建議清楚的區分開發人員角色和測試人員角色。 本文討論的是已經存在獨立測試團隊的情況，如何在敏捷開發中進行高效的測試。
實踐1：測試保護開發
通過快速的自動化測試跟進開發，保證新增和修改不破壞已經獲得的成果。
典型步驟如下：
1，開發人員根據需求，採用TDD，編寫代碼，實現界面和接口。
2，幾乎同步，測試人員編寫自動化測試，主要是黑盒自動化測試，也不排除白盒自動化測試。
3，一般保證，代碼出來後的第2天，相關的自動化測試代碼開發完成。
實踐2：成爲大敏捷團隊的成員
子實踐1：參加相關會議，如果是SCRUM，參加SCRUM所有要求的會議。
子實踐2：可以閱讀和修改最大範圍的配置項（比如文檔，代碼，工作項）
子實踐3：一起工作，比如把位子搬到開發人員旁邊，如果同時參加多個項目，選擇一個較近距離的位子。
說明：這個實踐本身的宗旨與傳統做法並無根本區別，這裏的區別在於程度。
實踐3：與定期構建一起執行測試人員的自動化測試用例，或者定期構建包括測試人員的自動化測試。
這裏用了”測試人員的自動化測試用例“，也有做法是測試人員和開發人員一起維護自動化測試用例，並沒有“測試人員的自動化測試用例“，這裏主要說明無論測試人員貢獻的自動化測試用例處於何種形式，無論構建是否包括測試人員的自動化測試用例，就是要求自動化測試能與構建爲基來執行。
子實踐1：維護一套自動化測試環境，可以自動獲得最新的##測試用例和構建成果
子實踐2：測試結果可以自動發佈到合適的地方，缺陷得到跟蹤管理
實踐4：設計更多黑盒手工場景化測試用例，安排更多隨機場景測試
關 注於局部功能的測試用例在敏捷開發中往往已經被自動化實現了。因此爲了發佈的測試中，值得設計更多黑盒手工場景化測試用例。選擇一些典型場景化測試用例開 發爲自動化測試用例也是可以的，但是此類測試用例的自動化開發所需工作量較大，要看測試團隊的投入和質量目標安排，如果有象微軟一樣的測試開發工程師，就 另當別論了。一般而言，從經濟角度出發，黑盒手工場景化測試用例是發現潛在缺陷的有效且經濟的手段，如果存在豐富經驗的測試人員，隨機場景測試也是值得更 多采用的。本實踐在傳統測試中也有，這裏要強調的特別之處是可以考慮手工測試全部用場景化測試，大幅減少針對單一功能或局部功能的測試用例。
對測試人員的要求
從以上實踐可以看到，測試人員所要掌握的技能有黑盒自動化測試、場景化測試，最好也要常握白盒自動化測試，定期構建和自動測試報告
工具支持
常見的有fit,fitnesse, white, watir, selenium, cruisecontrol, QTP, robot, xUnit系列，xFit系列等等
效果和校驗
上述的實踐是否有效、是否高效，可以觀察如下幾點：
1，達到發佈條件所需的測試輪次是否減少？測試缺陷密度是否減少？
2，獲得快速發佈的能力，發佈工期偏差是否減小？
3，測試所需總的工作量是否在測試團隊承受的範圍之內，尤其關注測試後期的工作量是否大幅減少，減少的數量是否比在測試前期增加的數量要更大？
如果沒有獲得正面收益，就需反思了。