敏捷開發過程中測試團隊的職責和產出是什麼？
更細一點來描述問題:
1. 敏捷開發過程中, 相關的系統分析文檔, 設計文檔. 對應的測試分析文檔, 測試用例, 是否需要按質量完成.
以前聽過一個據說非常成功的案例, 說在敏捷開發過程中, 測試是使用一張紙的測試文檔的, 這張紙寫清楚需要測試的點, 然後開始測試.
2. 關於需求, 敏捷開發過程中, 是否需求方只需要提供一個用戶故事, 比如 "我作為PD(代表用戶的意思), 在某些場景中期望達到什麼目的, 所以希望產品如何如何." 而具體的詳細設計在開發過程中邊設計邊討論.
3. 敏捷開發過程, 是否可以等價於迭代式開發, 比如, 將某個產品分成幾個部分, 先完成某個部分, 再完成其他部分, 或者先做出一個基本原型. 此原型能夠實現基本功能, 再次基礎上繼續完善其他功能.
這樣的說法, 本人基本贊同, 但是會演變成另外一種情況, 就是需求人員自己都沒想好整體產品的細節, 先把想好的實現掉, 再實現的過程中, 再慢慢想其他功能.
1.敏捷中文檔輕量化，但是並不代表不保證質量。敏捷是減少不必要的文檔，減少重複文檔，敏捷中不會出現傳統開發中分的那麼細的各個階段文檔，你可以看下scrum中的backlog，這個文檔可以從需求貫徹到測試整個過程。對用戶故事，計劃估算，實現方法，如何測試等內容都有描述。
2.是提供用戶故事，但是用戶故事粒度比你說的會細化很多。敏捷過程中同樣不允許出現需求蔓延情況。一個用戶故事是能夠帶來用戶價值的最小需求單位。用戶估算不管如何實現，但是一定是會把需求說清楚。
3.迭代只是敏捷的一個特徵，而不是全部。敏捷更加重要的特徵是通過短周期迭代而帶來的團隊不斷自適應和調整。敏捷方法中需求人員在迭代1當然沒有必要想好後續所有迭代的產品細節，但是一定要想好整個產品的功能規劃，即對產品的高端規劃和設計還是要有。關於敏捷開發中如何做測試的具體案例，在如下這個回答里我已經介紹過一些，可以參考：
- Scrum敏捷開發中的測試工作應該如何開展？
關於一頁紙的測試文檔，我以前也做過類似的事情，而另一個我聽到的案例來自於Agile Testing
Days 2012大會上，Dawn Haynes的演講「Agile Test Planning Documentation: Needed? How Much? How?」。
- Agile Testing Days 2013 – Program
- 如需要她的演講材料，可以聯繫我獲取
我覺得,不管是不是敏捷開發。對於測試團隊的職責和產出是沒有影響的。
職責始終應該是根據需求來檢驗產品質量，保證最後遞交的產品符合出口準則。
產出應該就是各類測試報告。
1. 敏捷開發過程中, 相關的系統分析文檔, 設計文檔. 對應的測試分析文檔, 測試用例, 是否需要按質量完成.
這些文檔視情況而寫，對於框架平台的，設計文檔可能會要求嚴一點；業務開發，可能
會只需要畫幾個類圖而已。但是不管如何，測試用例我們是要求寫的。對於測試用例質量的要求與傳統敏捷開發一樣
2. 關於需求, 敏捷開發過程中, 是否需求方只需要提供一個用戶故事,而具體的詳細設計在開發過程中邊設計邊討論.
用戶故事往往在實際開發中不夠，因為價值的東西都是相對高層的東西，實現的時候還需要細化，可以使用用例、業務規則等形式細化，檢驗的標準就是開發人員能夠理解需要做什麼，知道有哪些流程。詳細設計肯定是在開發過程中去做的，但是在估時時會進行簡單的設計，這個準確度是隨著團隊經驗以及能力提高而提高的。
迭代開發並不是敏捷開發，它只是敏捷開發的一個方面。就但說迭代，有沒有固定周期、有沒有價值目標就是敏捷開發中的一些要素。
個人覺得在敏捷團隊中，測試的難度和挑戰比瀑布模式大的多。不斷變更的需求，技術重構，從story到迭代版本的基本驗證，測試...
因此測試的主要職責可以包括以下的幾點：
1.需求的把握。測試要對不斷變化的需求都能把握住，以PO（product ower）的標準來要求自己，敏捷的要旨是小步快跑，保證每一步都是對的，這樣在團隊中就需要有人來保證我們做出來的東西是沒有偏離需求的，這個角色只有測試勝任；
2.團隊節奏的控制。不知道大家有沒有做過敏捷項目，迭代不斷的出現延遲，問題單越來越多，大家疲於根據計劃加班。這個時候我們可不可以把下個迭代要做的事情暫時先停下來，留一個迭代或者半個迭代來解決問題，重新讀下代碼，找出那些異味的代碼（smelly code）重寫一下。找找我們流程中的問題並改進。這個事情也是由測試人員來提出比較合適；
3.質量控制。
這當然是測試的傳統的工作，找出問題，讓開發人員來解決。對於一個tester來說，質量控制Quality Control比質量保證Quality Assurence更重要。在敏捷階段，不是說發現的所有問題都需要馬上讓開發人員去改，因為或許這個bug對應的需求還不明確，或許下輪的重構就能自動解決問題，或許當前這個迭代使用的技術解決這個問題代價太大... 總之，這裡是比較靈活的，也是比較考驗測試人員的經驗的，什麼問題應該馬上解決，什麼問題可以討論。
另外，關於質量控制比較重要的一點是分清楚測試階段，這點在國內的公司很明顯，單元測試，集成測試覆蓋率低，或者乾脆不做，或者做了沒啥作用，每當大家回去做問題回塑，會發現很多問題應該在ut或者st階段發現。那麼這裡的測試人員要不要去做這些測試，如果要做怎麼做，這個對於不同形態的產品或許答案完全不一樣。自己參與過的大型產品中測試人員都是做集成測試的，只是這個過程對測試來說比較痛苦，需要了解代碼，有一定的編碼能力。
另外，測試的產出這個有點不好界定，產出這個東東感覺是和流程比較強相關的，我在流程的哪個階段必須產出什麼東西。文檔，測試分析，問題單，測試需求分析等等。。。 這個也是和產品的形態有關，如果是輕量級的產品完全不需要做很多事情，或者很多事情可以合併來做，產出一份文檔或者結果就可以。
1，文檔要全，而且要保證質量，不過測試用例例外，看情況而來。
敏捷團隊有建議的人數規模，測試人員應該著眼於關鍵點，一個全面的測試用例也常常被證明40%以上的用例是徒勞的。測試人員應該具備出色的test sense，根據經驗能夠判斷出哪裡是潛在bug、缺陷和主要數據流關鍵點，針對這些地方寫測試用例，方便管理也能夠判斷數據流階段性的正確。還有就是TDD在開發過程中的保證，前期的需求討論，測試人員參與程度應比開發人員更高，而系統架構確定、軟體架構確定，都是由開發和測試共同決定，並在開發過程中出現需求變動，也保持軟體架構的相對穩定，因為軟體架構的改動對於測試人員來講不單單是改動，很可能是重新來過。
2，這個不管是不是敏捷的，前期都盡量挖掘客戶的需求，不留下任何潛在的需求。開發過程中的需求變動，根據經驗來說，還沒有遇上過需求不變的。這個其實是很無奈的，這是由客戶方不夠專業引起的，這也確實沒有辦法，只能是期望變動不是翻天覆地的。
3，開發過程差不多，或者說一樣也可以，但敏捷方法對人員上的控制有一些建議，來使人員工作效率更高，交流成本更低。在這方面來講，敏捷對於人的性格也有要求，不是每個人都適合參加敏捷開發，在搞人這方面上，敏捷只是提出了一些建議，最佳實踐還是得根據公司人員和公司內部結構的實際情況來定了。
我補充兩點吧，第一，在敏捷裡面測試有一個很重要的產出就是自動化測試，有了自動化測試之後測試人員有更多的時間去做探索性的測試，並且自動化測試能夠給予團隊一個很好的反饋，你改動了代碼之後是否對系統有影響都能及時的反饋出來。第二，測試團隊對需求的影響。測試人員在設計測試用例時就會對用戶的場景和預期的行為有一個描述，就會出現一些產品人員考慮不到的情況，這樣便可以更加完善需求，提升產品的體驗和質量。
職責沒有變化，但是意識要有很大的變化。
意識需要從發現Bug轉變為預防Bug出現，
從越多發現Bug轉變為越早發現Bug
其他19個答案都認真拜讀了一下，說的都有道理，但是沒說到根上。
前幾天我們研發部例會上有一次討論，研發部長建議我們在研發流程里加上更多質量措施。
我給的建議是，把團隊里能力差，潛力低的員工全部調出團隊，他們不適合混互聯網。
不知道我的答案樓主能否理解。
1.文檔的量我覺得可以少些，過多的文檔是不符合敏捷開發的理念的，但是文檔的質量必須得到保證，測試用例的覆蓋一定要夠，像你說的那個成功案例，雖然只有一張紙，恐怕上面也有著大量的測試用例吧
2.我覺得雖然敏捷開發可以邊開發邊設計細節，但是明確的需求肯定是必須的，任何一個設計在確定時最好先想想這個設計是否能讓迭代順利。
3.我覺得敏捷開發就是迭代式的開發，確實有可能出現邊實現邊設計的情況，這也是很難避免的，因為需求時刻都有可能發生變化。所以，測試人員應該及時跟上開發和需求人員的腳步，及時地更新測試用例，並提醒大家需求的變更是不是超過了限度，該控制控制了。
測試團隊的主要職責是儘早給出質量反饋，做到風險前移：
1) 最早在需求討論階段，幫助需求和開發對需求有正確和共同的認識，例如主導更多的用戶場景、異常等討論
2) 用於測試的用例同樣有優先順序，最高的優先順序是「用戶使用最多」以及「最容易發生bug」的場景交集
3) 縮短測試時間，更多使用自動化，例如Cucumber、Fitness、Selenium等的使用
4) 測試工作的過程和結果可視化，方便團隊內的溝通
另外，測試團隊需要有一線工作的意識：測試人員需要參加計劃、估算、執行、回顧等與產品交付相關的任何環節
我認為敏捷測試是為了讓測試團隊回歸測試的本質，即驗證功能性能，預防與發現Bug，測試不是為了出文檔而進行的，測試的質量不是由文檔來決定的，關鍵是測試的人員。敏捷測試正是強調參與人員的重要性。對於比較簡單的場景，減化必要文檔能提高測試的效率，但對於比較複雜的場景，添加必要文檔也許可以提高效率。
1. 關於輕文檔的說法
之前也看了些關於敏捷模型和方法的介紹性文章，對其中「輕文檔」的概念是深信不以，自己誤將「輕文檔」理解為「無文檔」了 ，這下出亂子了，在一段時間裡需求和設計都是採用口口相傳的方式，完全靠個人的理解和記憶力，使所有成員都處在混沌狀態（畢竟這種方式對人的要求太高了，按照當前中國企業人員現狀，大家都懂的...），最後連產品經理自己都不記得當時是怎麼設計的了，後來改成了設計討論優先，技術同學可以開始開發，此時交互設計師同步撰寫設計文檔，在產品開發過程中再不斷完善這個文檔。
但是文檔本身也必須講究輕量級，將主要的邏輯和需求明確清楚，對於異常問題可以隨著後續的開發進程進行補充。
對於測試的一張紙的問題，我覺得一張兩張或者三張的這種形式並不重要，重要的是測試用例是一定要有的，另外測試人員也需要對每個迭代所要達到的目標爛熟於心，這點個人覺得很重要。
2. 關於需求的這個觀點，其實我個人只能贊同一半了，贊同的是需求可以通過user story card進行傳達，但是設計不是要等到開發時才出，而是要將本迭代需要開發實現的需求要同步討論和給出設計來
3. 這點贊同人月神話的回答，我再補充一點，「比如, 將某個產品分成幾個部分, 先完成某個部分, 再完成其他部分, 或者先做出一個基本原型. 此原型能夠實現基本功能, 再次基礎上繼續完善其他功能「的這個說法，我個人不是很贊同，敏捷的迭代應該是盡量將產品所要傳達給用戶的最有價值的功能先行實現，而不是簡單的說是先實現幾個部分再實現幾個部分前面的回答已經很完善了，我來補充下第二、第三個問題的看法：
第二個問題：「是否需求方只需要提供一個用戶故事」，這樣的說法有點問題，用戶故事的產生需要PO和用戶一起商議決定，其來源始於用戶（需求方），但其產生過程實際是PO對原始需求的分析和拆解過程，傾注了其對需求的理解和判斷，故對於團隊來說，用戶故事是由PO提供的，且PO和用戶的討論交流過程中，用戶不一定需要提出完備的用戶故事（當然用戶能夠且願意和PO一起分析需求更好）。後半句的回答：詳細設計是在迭代中細化的，但迭代計劃會議時，團隊成員就應該對用戶故事實現的概要設計達成一致（主要的設計思路和難點風險點，UI草圖等）。
第三個問題：敏捷不等於迭代開發。相對於迭代開發，敏捷從形式上看更強調一種節奏感（即長期的穩定的團隊生產力的輸出、穩定的交付節奏、預期可見的交付物等）。「需求人員自己都沒想好整體產品的細節, 先把想好的實現掉, 再實現的過程中, 再慢慢想其他功能」，整體產品的細節作為需求人員來說不一定需要都清楚，需求人員只要對產品的整體結構以及長遠的規劃有個大體的把握就可以開始迭代了，而且其實現實情況往往是這樣的，需求是在發展變化中的，需求的不斷實現過程中往往會催生出新的需求，甚至會推翻之前的一些需求。剛開始做一個大而全的規劃反而不好，這也正是敏捷靈活機動的所在。
敏捷是以小團隊快速迭代為主，一般不會劃分明確的測試團隊，編碼團隊或是設計團隊。更多的是以角色來劃分，一個人可能有多重角色，一般來說測試是貫徹開發始終的。
回到問題，測試的職責就是確保生產的產品是有效的，其產出就是有效的產品。一段未經測試的代碼，其價值等於零。
敏捷的迭代周期不宜過長，一般會按周來完成整體團隊級別上的迭代。更小的任務單元迭代會更快，每個函數都可以有自己的迭代過程，從設計編碼到單元測試完成。甚至於單元測試本身也會經歷設計編碼測試的過程。
從提問者的問題來看，還處於傳統的軟體開發思維，敏捷最重要是價值觀和思維的轉變。
至於文檔的問題，回到敏捷的價值觀，我只能說，必要的文檔就是必要的。如何權衡，不是有個現成的模子我需要AAA、BBB、CCC文檔來套的。如果實在覺得難以操作，可以參考成熟的敏捷流程，如絲瓜母。敏捷測試關鍵成功要素
1.使用團隊整體參與的方法
2.採用敏捷測試思維（直接交流、靈活應對變化、鼓勵嘗試新技術方法嘗試最簡單的方法來滿足測試需要。）
3.自動化回歸測試（自動化冒煙測試、自動化單元測試）
4.提供並獲取反饋。
5.構建核心實踐的基礎（持續集成、測試環境、管理技術債務、增量工作、編碼和測試同一過程）
6.與客戶合作
7.保持大局觀
敏捷中根本沒職責的概念，沒有測試、開發的分工，兩種角色可以互換。但是這種要求對現在我們的團隊來說，有點困難 。
文檔，敏捷其實不等於無文檔，只是要產出必要的文檔，在一個小團隊里，如果人員足夠自主的話，充分的溝通是可以代替文檔傳遞項目內容的。但是這個我們也嘗試失敗了，主要原因還在於人員問題。
人員，我曾經問一個培訓老師，敏捷是不是對人員要求不顯著，可以通過團隊來彌補一個新人的技術能力問題？雖然回答是肯定的，但是我們嘗試過，其實敏捷對人還是有一定要求的，最少的要求是主動性強。
敏捷和瀑布哪個好？其實一個開發模式沒有自己的好壞，要看適合與否。瀑布模式會流程感強一點，而且留下的文檔對於產品的長期維護還是有幫助的。敏捷中產出的文檔太少，項目後期若不補充文檔，產品長期發展是不利的。
如果一個團隊人員自主性不強，主動性也不好，能力普遍不強，其實這樣子情況瀑布模式反而會讓人覺得過程可控（感覺上的）。並且這種情況下，個人感覺瀑布和敏捷差別不大。
測試的職能在不同公司的職責和產出是不同的 但本質就是職務本身 測試產品
我認為更重要的是在敏捷中如何讓技術與測試協作起來 減少溝通黑點盲點 提高工作效率
因為效率才是敏捷的真正的意義
這是敏捷項目中技術們的工作 那麼如何在做完工作的下一秒就讓測試知道呢
一般情況是跟測試說一下 那還有沒有更快一點的方法
就是在一個看板里加入測試看板
魚骨精益敏捷看板集產品、技術、測試、設計於一體
產品建好需求 技術認領工作 完成後直接拖拽到測試中 測試一秒收到通知開始測試
動作一氣呵成 大幅減少時間的浪費 提升工作效率！為您推薦魚骨軟體
僅以我的理解，寫下我的答案：
1. 敏捷開發過程中, 相關的系統分析文檔, 設計文檔. 對應的測試分析文檔, 測試用例, 是否需要按質量完成.
以前聽過一個據說非常成功的案例, 說在敏捷開發過程中, 測試是使用一張紙的測試文檔的, 這張紙寫清楚需要測試的點, 然後開始測試.
首先，我認為一張紙的測試文檔說明了測試文檔需要簡潔明了，條理清晰。測試人員之間能夠一下明白其他同事的測試例。
其次，那麼如果來保證測試過程中文檔的質量呢？我認為擁有一個質量保證體系很有必要。前前公司在整個測試流程中遵循TL9000質量體系，對每一個環節，小到testcase的命名規範都有詳細的要求。
同時，在敏捷開發過程中，需要同事之間高效的協同，開發與測試需要足夠的溝通，相互理解需求才能最大程度上保證開發設計文檔，測試用例設計等各環節的效率和質量，避免後期出現返工。
2. 關於需求, 敏捷開發過程中, 是否需求方只需要提供一個用戶故事, 比如 "我作為PD(代表用戶的意思), 在某些場景中期望達到什麼目的, 所以希望產品如何如何." 而具體的詳細設計在開發過程中邊設計邊討論.
就我目前的理解，我覺得如果需求方（假設是外部客戶）是這樣的需求的話，我是不敢接這活的（雖然我只是一個小兵o(╯□╰)o）。
you know，一方面，商業合同問題。公司需要明確客戶需求，開發之前，需要對客戶要求的每一個功能寫到需求文檔中。對於軟體公司，也許小到一個參變數的定義這樣的細節，都需要跟認真的客戶交代清楚。萬一產品交付了，客戶說你這不滿足某某需求怎麼辦，拿什麼說事兒呢？
另一方面，這是對員工的負責，無論是作為老大還是底下的小兵都不能忍受需求無數次被臨時更改的痛楚。
當然，大部分詳細設計還是需要開發測試一起討論通過的。
3. 敏捷開發過程, 是否可以等價於迭代式開發, 比如, 將某個產品分成幾個部分, 先完成某個部分, 再完成其他部分, 或者先做出一個基本原型. 此原型能夠實現基本功能, 再次基礎上繼續完善其他功能.
這樣的說法, 本人基本贊同, 但是會演變成另外一種情況, 就是需求人員自己都沒想好整體產品的細節, 先把想好的實現掉, 再實現的過程中, 再慢慢想其他功能.
我覺得基本可以這麼理解。
前公司28在產品設計階段就是採取的迭代式開發。一個correction需要每周合入基線版本中，哎，苦的是開發同事，更苦逼的其實是測試，補丁無數。
給足錢再說事
1. 角色可能會臨時轉化, 但是各自的指責沒有丟. 比如: 測試可以開發, 產品可以測試
2. 因為周期比較短, 所以要提高測試效率 比如: 持續集成思想, 回歸自動化, 測試點代替測試用例
3, 測試要更積極, 主動溝通, 主動推著問題解決, 問題解決越早越好
4. 每個周期的總結也很有必要
敏捷過程中，測試的主要職責應該是對每次迭代的產出物做驗證，確保產出物滿足產品設計需求，質量合格。
誰有騰訊和淘寶的敏捷開發模式的分析文檔
推薦閱讀：