“人”是重心，方法、策略是輔。為了適應不同的團隊結構，不同的項目環境，敏捷項目和敏捷活動的實踐也應該因“人”而異，但是，并不是說可以天馬行空，我行我素。一旦脫離了正確的敏捷方法、和敏捷原則的指導，我們的敏捷活動就好比摸黑前行了。
這正是我們需要學習前輩和敏捷主義大師們的經驗意義所在了，筆者在過去的實踐中受益頗多的也正是前人的實踐經驗和方法。因此，學習前人的經驗和方法，并運用這些最佳實踐來幫助敏捷開發團隊，甚至是傳統團隊來解決時下重要的問題是十分有意義的事情。筆者不敢妄自尊大將自己的一般實踐納入經典方法范疇，但經歷了兩年的研究和改進，筆者提出的敏捷測試的原則也得到了業內同僚和“大師”的普遍認可。經過多次和其他項目團隊的經驗交流，我們也不斷的改進著我們的原則、方法。因此，筆者要非常感謝參與討論的同僚們，沒有你們的熱情參與，也不會有今天的筆者信心百倍的執筆了。正如筆者在借鑒了前人的成功案例中的經驗和方法之后定制了符合項目需求的測試原則一樣，相信，讀者們在閱讀了筆者的敏捷測試原則和方法后，同樣也會有所收獲。而對筆者經歷的敏捷實踐活動中的方法和測試模型的講解將成為我們講述敏捷實踐的第二步，也是本文的重點。
綜上所述，筆者將運用本文的主要篇幅為大家講解這個敏捷實踐。它們是：
敏捷團隊組織構成，敏捷測試團隊的任務和使命；
敏捷開發團隊以測試為驅動的開發方式——測試驅動開發，這是種獨特的測試？還是開發？
遞增型的迭代測試，它首先是對敏捷測試過程活動和生命周期模型的介紹，通過學習經典的敏捷增量測試模型，我們將敏捷測試的各類活動有機的組合到了一起。在此之上，對定制后的獨特敏捷增量測試模型的分析和理解，幫助我們理解測試活動的規劃和管理；
以及需要特別關注的遞增型迭代測試的關鍵活動之一——“靜態測試”；這也是筆者認為的最高難度、最具影響力的敏捷測試活動。它將測試團隊最早的引入產品開發環節，測試人員以第一用戶的角度判斷設計的有效性，此活動較早的暴露了設計缺陷、避免了團隊對目標的不一致理解等，是測試活動中最有創造性價值的部分；
最后，筆者將談談測試活動中的測試計劃和管理，即關于測試任務估計，測試活動計劃，各個重要測試活動時間分配與安排的介紹。
然而，敏捷測試不是一蹴而就的，做到真正的敏捷，無論是從傳統測試模式向敏捷測試的過渡，還是組建全新的團隊都是需要循序漸進的，同時也需要團隊成員的通力合作和不斷的實踐來完善敏捷測試的實踐原則和方法。
敏捷團隊
考慮到敏捷團隊的組織結構，讓我們以筆者親身經歷的項目為例來說明。筆者曾共事的整支產品開發團隊被劃分成 4 個相對獨立的敏捷開發隊伍，而每支隊伍擁有相同配置的 7 名成員，他們分別具有不同的職能屬性。如圖 1 所示，每支敏捷隊伍組成成員角色包括 1 名 UCD（User Centered Designer），主要負責產品的主要設計，其工作主要包括界面設計、用戶的用例設計等等； 1 名 Visual Designer，主要負責產品界面的色彩搭配、控件的外觀設計和 UCD 界面設計方案的初步實現和美化；1 名 Information Developer，主要負責產品中信息的編輯和重要文檔的撰寫工作； 3 名開發人員，主要負責產品的實現。和 1 名 QA，主要負責產品質量的保障。（更多的我們將 QA 定義為具有相比于測試人員擁有更多責任的一個職能，在本文中，為了簡便起見，我們仍稱之測試人員）。4 支敏捷的隊伍擁有相同的 SCRUM MASTER STAKEHOLDER。通常會在同一時間進入一個迭代周期，制定各自的敏捷計劃，并在同一時間退出，發布各自功能實現。而 4 支隊伍的勞動果實被集成到一起就形成了可發布的產品了。
圖 1. 敏捷開發團隊的組織結構
因為敏捷團隊中只有 1 名測試人員，因此需要一臂承擔測試策略的制定，測試計劃，測試腳本，測試用例設計以及測試的執行，幫助團隊發現潛在問題，并協助解決問題的工作。敏捷團隊的敏捷原則也是測試人員敏捷活動的規范，測試也需要擁有和團隊的良好溝通，高度迭代的活動和不斷的獲得 STAKEHOLDER 的反饋。那團隊的結構與敏捷本身有什么直接關系呢？與敏捷測試又有多少關聯呢？
談到這里，想起曾經有朋友向我咨詢有關敏捷團隊的某些職能的人力配備的問題。其實，筆者也無意論證 7 個人為什么是最佳組合，為什么不是 17 個，20 個人的組合。但是，敏捷原則告訴我們敏捷團隊是高度協同、民主和平等的團隊，為了讓團隊中每個人充分高效的工作。相同職能下的組員至多不好超過 3 名，最佳配置也是不同職能下配置 1 個人頭。因此、在這樣一個小型、平行的組織結構里，溝通更加易于建立，溝通復雜度也相對較低，相比 17、20 人的團隊組織，溝通的代價也小很多。相反，很難想象在一個敏捷團隊中會擁有諸多不同風格的執行者，決策者將是個怎樣的混亂情況。
此外，經歷過敏捷測試的體驗，我們發現一個單一的敏捷團隊最好保持較小的“尺寸”。這是因為擁有很多測試人員的敏捷團隊通常不但需要更大的實際工作量來匹配龐大的機體而導致團隊任務量更巨大，更復雜，失去自我管理的信心，而每個測試人員也將要花費大量精力和時間投入到內部溝通，和可能因為內部缺乏一致而導致的更加頻繁的反復溝通中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
