敏捷 反應快速靈敏。
在敏捷軟件開發領域，更注重的以人為核心，迭代，循序漸進的開發方法。相比傳統的開發方法，這種方法能更快速的開發，上線，反饋，調整、迭代。以敏捷的姿態去發展產品。
敏捷與傳統開發的區別
有個非常有意思的游戲能夠幫助大家理解敏捷和傳統開發的差異。游戲有兩個角色，一個是“老板”，另一個是“員工”，在 2 分鐘內，“員工”需要在“老板”的完全指揮下，即“向前一步，向后一步，停，向左一步，向右一步”，完成 60步移動的任務。“員工”需要執行“老板”的每一個指令，不允許做出相違背的動作。“老板”則不參與行動，只發出指令指揮“員工”的活動。我們體驗這個 游戲 時，當場 60% 的參與者成功完成了任務，大致估計出我們的工作效率是50%*60%=30%。游戲后，參與者被問及對這種行為方式的感受時，無論是“員工”還是“老板”都表示非常不滿。
接著，大家又做了另一組游戲。2 分鐘內參與者被要求獨立的、自主的完成 60 步移動任務，在這次游戲里，所有參與者任務相同，大家可以自行決定、并依據自己的判斷隨時調整其步伐方向，快慢。最后，我們發現所有參與者不但毫無折扣的 按時完成了任務，因而工作效率也達到 100%*100%=100%，而且所有人對于這種新的工作方式更是產生了極大的興趣。
敏捷開發與傳統開發的比較
通過上面有趣的兩種游游戲的對比，以及價值表述的對比就折射出了傳統開發與敏捷開發的方式的對比，其中的優劣不言而喻。
敏捷開發
敏捷宣言：
敏捷方法分類：
除了圖例中的方法外還有 Crystal, Lean Software Development, Feature Driven Development, Xbreed, RUP 等等。
敏捷方法的共性： 雖然各種敏捷方法的名稱、所需環境、適合的團隊有很大差異，但是他們擁有相似、相同的以下幾大特點：
* 擁抱變化
“唯一不變的就是變化”所以，需求的變動是必不可少的，每次的決定和需求的調整都是將產品開發推向更正確的方向。而在接受變化的同時，我們應該積極的反饋顯示活動中暴露出來的可能的設計缺陷和錯誤。
* 客戶的參與
最終使用者、內部使用者、客戶代表、商業伙伴都可以是我們的客戶。對于客戶的參與更能使我們做出客戶真正需要的產品。
* 較少的文檔
傳統開發的文檔在敏捷中仍有大用，只是我們可以將原來的文檔進行精簡。在敏捷中文檔不是最佳的溝通方式，更鼓勵通暢的交通和溝通，而溝通的效率遠高于文檔。
* 最大化的生產力
敏捷開發模式要最大化的提高團隊的工作效率。無論是依靠剪除冗余的文檔工作，還是提供民主的、通暢的溝通平臺都是為了幫助 團隊能夠集中有限的精力處理。
* 測試驅動開發
是讓開發人員在編寫功能代碼之前，根據對需求的理解先設計和編寫單元測試代碼。先思考如何對將要實現的功能進行驗證，再考慮功能的實現。然后迭代的增加新功能的單元測試和功能代碼編寫，直到完成全部功能的開發。
* 自動化冗余工作
將團隊成員從冗余的勞動中解放出來，無論是自動化的測試還是自動化工具的開發只要能夠節約成本都是敏捷開發、敏捷測試的目標。
* 民主的團隊
敏捷團隊是一支民主的團隊，團隊關系是平行的，每個團隊成員能夠平等的參與討論，決策。傳統開發的垂直的官僚機構在敏捷開發中已是過時的。
敏捷測試
不是說敏捷測試么？這怎么看上去測試跟敏捷沒一毛錢的關系。人家都敏捷了，還要測試做什？
在敏捷開發流程中，測試不再是瀑布試開發流程的一個環節，而是全程參與整個開發流程。通過各種方式來保證產品的質量，無論是原則中的“頻繁交 付”，還是對“可工作的軟件”的度量，或是敏捷開發實踐中的“測試驅動開發”，“行為驅動開發”，都離不開測試的支持。 當然，敏捷測試對測試人員提出了更高的要求，對測試人員來說也是新的挑戰。
敏捷測試人員的定義
專業的測試人員，適應變化，與技術人員和業務人員展開良好的協作，并理解利用測試記錄需求和驅動開發的思想。
敏捷測試人員往往具有優秀的技術能力，知道如何與他人合作以實現自動化測試，同時也擅長探索性測試，他們希望了解客戶在做什么，以此更好地理解客戶的軟件需求。
敏捷測試思想
對于一個敏捷團隊而言，需要持續關注如何最出色地工作并發布最優秀的產品。根據我們的經驗，這需要大量的訓練、學習、時間、試驗和協同工作。
對于一個敏捷測試人員，他（她）會樂于收集和分享信息，與客戶或者產品負責人協作以幫助他們充分展示自已的需求，從而得到他們需要的功能，同時向所有人提供項目進展的反饋。
基本要求就是敏捷測試人員和其它敏捷團隊成員一樣，樂于學習新技能和面對新挑戰，不會僅僅局限于測試問題。這不只是測試人員的特征，所有敏捷團 隊人員都應具有。敏捷測試人員幫助開發人員和客戶團他解決可能出現的任何問題。測試人員提供信息以幫助團隊回顧和了解哪些方案有效，哪些無效。
測試人員可能在測試領域擁有特殊的技能和經驗，但一名優秀的測試人員并不懼怕參與一場設計討論，提供有且于測試性或者構建更良好方案的建議。敏捷測試思想是面向結果的、技術性的、協作的，樂于學習的、勇于不斷生產業務價值的。
測試人員的十條法則 敏捷測試人員的十條法則：
● 提供持續反饋
● 為客戶創造價值
● 進行面對面的溝通
● 勇氣
● 簡單化
● 持續改進
● 響應變化
● 自我組織
● 關注人
● 享受樂趣
提供持續反饋
既然是測試驅動敏捷項目，那么很顯然反饋在敏捷團隊中占據重要的地位 。既然是測試驅動敏捷項目，那么很顯然反饋在敏捷團隊中占據重要的地位 。
為客戶創造價值
敏捷開發就是在較低的版本發布中提供客戶目前最迫切需要的功能。這通常意味著限定范圍。我們經常在客戶團隊中遇到較酷功能的需求。任何人都可以質疑這些內容，但是測試人員會判斷其對故事的影響，因為他們需要考慮測試后果。
進行面對面的溝通
一個團隊如果溝通不好則難以協作。如今，許多團隊分布于多個地理位置，溝通變得更加重要和富有挑戰性。敏捷測試人員應該盡力促進溝通。這是把工作做好的關鍵因素。
勇氣
勇氣是極限編程的核心價值，類似測試自動化和持續集成的方式允許團隊實踐這種價值。 測試人員固守于自己的領域，不與其他業務相關者和技術團隊進行任何討論。雖然你找機會進入了協作的敏捷環境，可能會對找客戶索要實例或者找開發人員幫忙自 動化測試或者在每日例會時提出一個難題等感到不習慣。
當最初加入敏捷團隊或者當前的團隊開始過渡到敏捷開發模式時，通常你會產生恐懼感，并且存在大量的問題需要答案。我們到底如何才能在如此短的時 間內完成對每一個用戶故事的測試任務？測試如何跟上開發的節奏？如何確定需要多少測試？又或者你是功能測試經理或者質量過程經理，但不清楚在敏捷團隊中如 何定位自己的角色，也沒人知道答案。敏捷測試人員需要勇氣找到這些問題的答案，但需要勇氣的原因不僅限于此。
簡單化
敏捷測試人員和他們的團隊面臨的挑戰不僅是生產最簡單的有效軟件而且還需要采取簡單的方法以確保軟件符合客戶需求。這并不意味著團隊不應該花時 間分析主題和故事、思考合適的架構和設計。而是說，當業務部門的需求比較復雜的時候，團隊可能需要將方案退回給他們，更簡單的解決方案也會產生同樣的價 值。
簡單并不意味著容易。對于測試人員來說，這意味著采用能夠找到的最輕量級的工具和技術恰到好處地測試。工具可以簡單到只是一張電子表格或者清單。需要自動化回歸測試，但是應該把它們分解到最底層以獲取快速反饋。甚至簡單的冒煙測試也可能滿足面向業務的測試自動化。
持續改進
想辦法把工作做得更出色是敏捷測試人員應牢記的。
敏捷測試人員和他們的團隊總是在尋找工具、技能或者實踐以幫助他們增加更多價值或者得到更好的客戶投資回報。敏捷開發的短期迭代更易于嘗試新事物，以驗證是否值得長期采用。
學習新技能和提高專業技能水平對敏捷測試人員非常重要。可利用各種免費的資源提高專業技能。
響應變化
響應變化是敏捷實踐的重要價值，但是我們發現這對測試人員來說卻是最困難的概念之一。測試人員渴望的是穩定，所以他們會說：“我已經測試過了， 任務完成了”。持續的需求變化是測試人員的噩夢。但是，作為一名敏捷測試人員，我們不得不擁抱變化。周三，我們可能期望啟動故事A和B，下周五做故事C。 但是到了周五，客戶重新設定了優先級，現在需要故事A、X和Y。只要我們持續與客戶交流，我們就能處理這些變化，因為我們與團隊的其他成員保持同步。
自我組織
敏捷測試人員是自組織敏捷團隊的組成部分。團隊文化貫徹于敏捷測試理念。當開發人員、系統管理員、分析員、數據庫專家和客戶團隊持續關注測試和 測試自動化，測試人員就會獲得全新的視角。自動化測試很困難，但是當整個團隊都在為此努力時就會簡單得多。當大家具有多重技能和多層次視角時，任何測試問 題都會更容易解決。
當敏捷團隊面對一個嚴重問題時，比如進度障礙或者構建失敗，該問題將是所有人的問題。最高優先級的問題需要整個團隊解決。團隊應該立刻討論并決定解決的辦法和相關參與人員。
關注人
只有優秀的員工出色地工作，項目才會成功。敏捷價值和準則的宗旨是確保個人和團隊成功。敏捷團隊成員應該有安全感。不必擔心因犯錯受指責或者失 去工作。敏捷團隊成員互相尊重并認可個人成就。敏捷團隊的所有人應該有機會提高和發展他們的技能。敏捷團隊以可持續的步伐前進，使他們能夠遵循嚴格的實踐 和保持嶄新的視角。正如敏捷宣言所說，我們重視個人和合作超過過程和工具。
享受樂趣
在我們看來，測試人員的理想團隊是：所有成員協作，從項目的開始一直到結束，利益相關者與開發團隊共同工作，整個團隊負責質量和測試。相信很多人都認為每個人都應該在工作中找到樂趣。敏捷開發珍視敏捷測試人員對工作的激情。
敏捷測試人員的工作特別令人滿意，因為我們的角度和技能對團隊產生了真正的價值。
敏捷測試人員應該做什么？
看了這么多，你一定問：
測試人員在敏捷團隊中應該具備什么技能？
測試人員在敏捷團隊中從事哪些具體的工作？
在敏捷軟件開發過程中開展的測試就可以被稱作是敏捷軟件測試。因此，敏捷軟件測試并不是一個與敏捷軟件開發同一層次的劃分，而是敏捷軟件開發中 的一部分，與傳統的測試不同，敏捷軟件測試并不是一個獨立的過程，相反，它與整個敏捷開發中的其他活動交織在一起，處處都能看到它的影子。由于敏捷軟件測 試并不傾向于一個單獨的過程定義，本人認為從敏捷軟件測試與傳統測試觀點的比較、敏捷軟件測試中采用的方法、測試工程師在敏捷軟件測試過程中的工作等方面 來闡述。
回答的很含糊，個人認為敏捷測試人員應該具備的兩個主面。
首先，接納并理解敏捷的核心價值觀（溝通，簡單，反饋，勇氣，尊重、學習、分享）。
其次，測試人員應該具備測試基本技能，當然，可以擅長某個領域，如，探索性測試、單元測試。善于學習與分享，以學習的方式不斷的提高自身去適應團隊的需求。
我想說的是，不管是從傳統開發模式轉到敏捷測試，還是重新組建一個敏捷的測試團隊。并不是一蹴而就的事兒，需要長期的學習、摸索與改進。當然，前提是以敏捷的價值觀為指導思想。
-------------------------------------------------------------
本文引用資料：
段念《什么是敏捷軟件測試》
《IBM敏捷測試的最佳實踐》
《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》