敏捷社區的一些成員探討了幾種表述何如進行用戶故事的驗收測試的技術，以及測試整個主題的方法。

　　Charles Bradley介紹了幾種不同的描述如何進行用戶故事驗收測試的方法：

　　列舉要點(Bullet points)
　　在一個用戶故事卡片或者wiki上，以列舉要點的形式，把對系統行為的期望結果和實際結果記錄下來。這種技術適用于較小的或者簡單的用戶故事。
　　測試場景/數據……
　　把你測試需要用到的任何場景、數據都記錄下來。比如，用正確的/錯誤的/空的密碼來測試密碼功能。跟之前的方法一樣，這種技術通常非常適用于小的或者簡單的用戶故事。
　　先測起來
　　先進行一些測試，再洋洋灑灑把你需要驗證的系統功能記錄下來。這是一種比較易學的技術。這種方法適用于簡單的測試，也是其他方法不適用時的萬能鑰匙。
　　Given/When/Then
　　使用三段式：Given，When，Then。在Given部分，羅列出前提條件，測試環境，測試輸入以及系統狀態。在When部分，則列出一些觸發點或者狀態轉換事件。在Then部分，記錄系統行為，期望的輸出，或者下一個系統狀態。這種技術對于有著很多前提條件或者有特定觸發點的測試非常適用。
　　概念形態上的，帶有實例的規格說明書(Specification By Example-Conceptual Form)
　　編制一張表格，包含測試輸入和期望輸出。所謂概念形態，就是不以特定的值來描述數據。如果能比較容易地做出這張表格，那么使用這種方法就很可能非常有效。
　　互相搭配
　　選擇多種不同的方法應對不同的測試角度。

　　Peter Stevens則提出一個名為“如何演示”的測試表單。這個表單本質上是一個簡單的流程，描述了如何向產品負責人演示完整的用戶故事。他寫道：

編制“如何演示”表單是梳理產品待辦事項表的一部分，也就是說，這項工作可以在估算/交付計劃會議的時候進行，可以安排在首輪Sprint計劃會議的時候，也可以在項目的任何時候。它是會話交互的一部分，所以最好別定太早。

　　Lisa Crispin介紹了采用一張思維圖來規劃測試，以明確要完成的整個主題。團隊用了五輪迭代來完成她所指的主題，也就是十周的工作量。Crispin和另一個測試人員一起著手測試，在一塊白板上畫出了要完成測試工作的思維圖。接下來，他們和開發團隊、產品負責人、管理者以及其他利益關系人討論了思維圖。

　　在主題的實現過程中，測試人員常常會參照他們的思維圖。Crispin寫道：

最終，我們信心滿滿，我們已經從所有角度想過并討論過流程以及它對系統其它部分的潛在影響，我們還和所有利益關系人都聊了他們各自的要求和擔憂，同時，不止從功能層面，還包括性能和可用性層面，我們都做了充足的測試。