成功構建回歸測試的關鍵仍然在于是否能夠設計出優秀的規約界面，并針對規約界面進行測試。這樣，不但設計具有抗變化性，測試同樣具有抗變化性。而唯一可能改變的就只有實現了。在回歸測試的幫助下，代碼的變化是不足為懼的。我們把有關測試的詳細討論放在測試一節中。
組織規則
在后續的章節中，我們會詳細的討論XP中的一項非常有特點的組織規則－結對編程。這里我們需要知道，不同的團隊有著不同的組織，其迭代過程也需要應用不同的組織規則。例如，組織的規模，小規模的組織可以應用更快的迭代周期，如一周，在一個迭代周期中，團隊可以集中力量來開發一個需求，強調重構和測試，避免過多的前期設計。對于大的組織來說，可以考慮迭代周期更長一些，更注重前期設計，并將開發人員和測試人員的迭代周期交錯開來。團隊的組織構成也是影響迭代過程的主要原因。團隊是否都是由相同水平的人構成，每個人的專長是否能夠互補，團隊是否存在溝通問題。
(四)需求和故事
如何分析需求，如何記錄需求，如何將需求映射為設計，這些永遠是需求分析中最為重要的問題。XP提倡以一種簡單實用的態度來對待需求，而在軟件開發的歷史中，需求分析從來都是最需要嚴謹對待的工作流程。究竟誰是對的？
故事
每個人都喜歡聽故事，這也許是從小就養成的習慣。如果能夠把需求分析工作變成聽故事的過程，那該有多好。需求分析人員寫出一個個優美的故事，開發人員邊看故事，邊實現故事。也許這就是XP的設計思路所在。用戶故事，XP把需求變成了一個個故事，摒棄了枯燥無味的需求穩定。文檔的作用是傳遞信息，如果失去這個意義，再優秀的文檔也沒有任何用處。但是，完整細致、厚達數十頁的需求文檔是否真的能夠達到溝通的目標呢？對于大多數而言，恐怕看到文檔的厚度就已經心生懼意了吧。好吧，我們通過很多的輔助手段，可以強制要求開發人員都投入大量的精力來研究、學習復雜的需求文檔。但是這厚厚的需求文檔真的能夠完整的記錄所有的需求嗎？更糟糕的是，需求是會發生變化的，到時候如何維護這份需求文檔呢？回想精益原則，我們可以判定，這種處理需求的方式一定會產生大量的浪費。將需求做的盡善盡美需要成本，項目組的人員熟悉需求需要成本，維護文檔需求成本，解決不一致的問題也需要成本。那么，我們可以針對這幾點做一個分析：
需求的文檔是否要盡善盡美？需求文檔的最大目標是將信息從業務人員傳遞給開發人員（當然也會存在其它的目的，例如作為合同的組成部分）。那么，文檔是否完美和能否實現溝通效果并沒有直接的關系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
