最近讀了《測試人與敏捷團隊的五個約定》，很是贊同。但發現其并沒有緊扣敏捷開發測試的特點，這五個約定在傳統開發中已經早有實踐，也有相關論述。哪么在敏捷開發的測試方面有沒有不一樣于傳統開發測試的并且是有效的實踐？
從敏捷團隊的組建上來說，敏捷團隊并沒有要求安排專門的測試人員，甚至于在某些的方法中不建議清楚的區分開發人員角色和測試人員角色。 本文討論的是已經存在獨立測試團隊的情況，如何在敏捷開發中進行高效的測試。
實踐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、測試所需總的工作量是否在測試團隊承受的范圍之內，尤其關注測試后期的工作量是否大幅減少，減少的數量是否比在測試前期增加的數量要更大？
如果沒有獲得正面收益，就需反思了。