1樓：Zoe a
關於測試，如果是自己設計自己執行一張紙的測試文件或腦圖都可以，簡單省事。如果是多人協作的話，還是要規範用例的描述，還是推薦用工具，能避免遺漏且能沉澱資料。
關於敏捷和迭代式開發，這兩種還是有區別的，迭代式開發適合那些需求資訊不明確的專案；而敏捷開發是緊緊圍繞使用者需求，以使用者為導向。
以上產品圖來自研發管理工具Worktile 企業級專案協作與目標管理工具，感興趣的可以試用
Worktile 企業級專案協作與目標管理工具
2樓：寒先生的江雪
僅以我的理解，寫下我的答案：
1. 敏捷開發過程中, 相關的系統分析文件, 設計文件. 對應的測試分析文件, 測試用例, 是否需要按質量完成.
以前聽過乙個據說非常成功的案例, 說在敏捷開發過程中, 測試是使用一張紙的測試文件的, 這張紙寫清楚需要測試的點, 然後開始測試. 我覺得基本可以這麼理解。
前公司28在產品設計階段就是採取的迭代式開發。乙個correction需要每週合入基線版本中，哎，苦的是開發同事，更苦逼的其實是測試，補丁無數。
3樓：呂志鴻
敏捷測試關鍵成功要素
1.使用團隊整體參與的方法
2.採用敏捷測試思維（直接交流、靈活應對變化、鼓勵嘗試新技術方法嘗試最簡單的方法來滿足測試需要。）
3.自動化回歸測試（自動化冒煙測試、自動化單元測試）4.提供並獲取反饋。
5.構建核心實踐的基礎（持續整合、測試環境、管理技術債務、增量工作、編碼和測試同一過程）
6.與客戶合作
7.保持大局觀
4樓：王晶剛
1. 角色可能會臨時轉化, 但是各自的指責沒有丟. 比如: 測試可以開發, 產品可以測試
2. 因為週期比較短, 所以要提高測試效率比如: 持續整合思想, 回歸自動化, 測試點代替測試用例
3, 測試要更積極, 主動溝通, 主動推著問題解決, 問題解決越早越好
4. 每個週期的總結也很有必要
5樓：徐毅
關於敏捷開發中如何做測試的具體案例，在如下這個回答裡我已經介紹過一些，可以參考：
- Scrum敏捷開發中的測試工作應該如何開展？
關於一頁紙的測試文件，我以前也做過類似的事情，而另乙個我聽到的案例來自於Agile Testing
Days 2012大會上，Dawn Haynes的演講「Agile Test Planning & Documentation: Needed? How Much?
How?」。
- Agile Testing Days 2013 – Program
- 如需要她的演講材料，可以聯絡我獲取
6樓：周金根
1. 敏捷開發過程中, 相關的系統分析文件, 設計文件. 對應的測試分析文件, 測試用例, 是否需要按質量完成.
使用者故事往往在實際開發中不夠，因為價值的東西都是相對高層的東西，實現的時候還需要細化，可以使用用例、業務規則等形式細化，檢驗的標準就是開發人員能夠理解需要做什麼，知道有哪些流程。詳細設計肯定是在開發過程中去做的，但是在估時時會進行簡單的設計，這個準確度是隨著團隊經驗以及能力提高而提高的。
3. 敏捷開發過程, 是否可以等價於迭代式開發迭代開發並不是敏捷開發，它只是敏捷開發的乙個方面。就但說迭代，有沒有固定週期、有沒有價值目標就是敏捷開發中的一些要素。
7樓：廷和
我認為敏捷測試是為了讓測試團隊回歸測試的本質，即驗證功能效能，預防與發現Bug，測試不是為了出文件而進行的，測試的質量不是由文件來決定的，關鍵是測試的人員。敏捷測試正是強調參與人員的重要性。對於比較簡單的場景，減化必要文件能提高測試的效率，但對於比較複雜的場景，新增必要文件也許可以提高效率。
8樓：sunshine
敏捷中根本沒職責的概念，沒有測試、開發的分工，兩種角色可以互換。但是這種要求對現在我們的團隊來說，有點困難 。
文件，敏捷其實不等於無文件，只是要產出必要的文件，在乙個小團隊裡，如果人員足夠自主的話，充分的溝通是可以代替文件傳遞專案內容的。但是這個我們也嘗試失敗了，主要原因還在於人員問題。
人員，我曾經問乙個培訓老師，敏捷是不是對人員要求不顯著，可以通過團隊來彌補乙個新人的技術能力問題？雖然回答是肯定的，但是我們嘗試過，其實敏捷對人還是有一定要求的，最少的要求是主動性強。
敏捷和瀑布哪個好？其實乙個開發模式沒有自己的好壞，要看適合與否。瀑布模式會流程感強一點，而且留下的文件對於產品的長期維護還是有幫助的。
敏捷中產出的文件太少，專案後期若不補充文件，產品長期發展是不利的。
如果乙個團隊人員自主性不強，主動性也不好，能力普遍不強，其實這樣子情況瀑布模式反而會讓人覺得過程可控（感覺上的）。並且這種情況下，個人感覺瀑布和敏捷差別不大。
9樓：
1.敏捷中文件輕量化，但是並不代表不保證質量。敏捷是減少不必要的文件，減少重複文件，敏捷中不會出現傳統開發中分的那麼細的各個階段文件，你可以看下scrum中的backlog，這個文件可以從需求貫徹到測試整個過程。
對使用者故事，計畫估算，實現方法，如何測試等內容都有描述。
2.是提供使用者故事，但是使用者故事粒度比你說的會細化很多。敏捷過程中同樣不允許出現需求蔓延情況。
乙個使用者故事是能夠帶來使用者價值的最小需求單位。使用者估算不管如何實現，但是一定是會把需求說清楚。
3.迭代只是敏捷的乙個特徵，而不是全部。敏捷更加重要的特徵是通過短週期迭代而帶來的團隊不斷自適應和調整。
敏捷方法中需求人員在迭代1當然沒有必要想好後續所有迭代的產品細節，但是一定要想好整個產品的功能規劃，即對產品的高階規劃和設計還是要有。
10樓：ZeusYu
1.文件的量我覺得可以少些，過多的文件是不符合敏捷開發的理念的，但是文件的質量必須得到保證，測試用例的覆蓋一定要夠，像你說的那個成功案例，雖然只有一張紙，恐怕上面也有著大量的測試用例吧
2.我覺得雖然敏捷開發可以邊開發邊設計細節，但是明確的需求肯定是必須的，任何乙個設計在確定時最好先想想這個設計是否能讓迭代順利。
3.我覺得敏捷開發就是迭代式的開發，確實有可能出現邊實現邊設計的情況，這也是很難避免的，因為需求時刻都有可能發生變化。所以，測試人員應該及時跟上開發和需求人員的腳步，及時地更新測試用例，並提醒大家需求的變更是不是超過了限度，該控制控制了。
11樓：抽屜(chouti)
我覺得,不管是不是敏捷開發。對於測試團隊的職責和產出是沒有影響的。
職責始終應該是根據需求來檢驗產品質量，保證最後遞交的產品符合出口準則。
產出應該就是各類測試報告。
Java開發過程中如何更快的提公升自己？
語憶情感研究所 基於之前所了解到的，提高技能與能力的最有效的方法 不光是程式開發領域 來回答一下這個問題吧。其實這也是學習任何知識 技術的一攬子解決方案。我們先來介紹下 Deliberate Practice 刻意練習 這個概念，它最早由美國心理學家安德斯艾利克森博士提出 1.刻意練習，是 一萬小時...
軟體開發過程中如何控制需求變更？
新星軟體造價諮詢 需求澄清階段 讓業主派遣懂軟體技術的人員參與，盡可能把問題在這個階段爆出。軟體開發階段 如果需求變更不可避免，說清楚變更後對專案交付是否有影響，或者對其他需求是否會有影響，讓業主自己判斷唄。 阿斯特軟體 專案開發之前一定要做原型和效果圖，客戶確認沒有問題簽合同再進入開發流程。如果是...
在量化策略開發過程中，你都用到了哪些知識？
guobz 作為乙個純理科出身做alpha的我來說，優勢點在於數理統計，所以主要用到了數學統計知識，而計算機 金融知識其次，總結如下 數學統計方面 凸優化 多元線性模型 顯著性統計檢驗 方差分析 建模分析 線性代數 計算機方面 主要是程式設計，語言來說Matlab R Python都可以，只是工具，...