敏捷
反應快速靈敏。
在敏捷軟件開發領域，更注重的以人爲核心，迭代，循序漸進的開發方法。相比傳統的開發方法，這種方法能更快速的開發，上線，反饋，調整、迭代。以敏捷的姿態去發展產品。
敏捷與傳統開發的區別
有個非常有意思的遊戲能夠幫助大家理解敏捷和傳統開發的差異。遊戲有兩個角色，一個是“老闆”，另一個是“員工”，在 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敏捷測試的最佳實踐》
《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》
轉載地址：http://blog.csdn.net/fnngj/article/details/8597050
