我們正在轉向更精益的方法，看板很多。我們開始將我們的用戶故事分解爲很小的用戶故事，但是有很多問題正在提出，哪些故事應該有驗收測試，哪些不應該。爲「精益」用戶故事編寫驗收測試
例如，我們已經分手一個故事變成2.首先創建一個實體和一些基本領域。另一個擴展在這些領域，並增加更多的功能。通常我們會在第二個故事結束時編寫驗收測試。但是，我們現在應該寫一個小的驗收測試，我們有一個較小的故事，然後在我們做第二個故事時擴展驗收測試（s）？
它的論點是，所有的故事都應該是可測試的，反證的論點是它的反傾向性，因爲我們正在分裂故事以讓他們更快地接受測試人員，但是通過編寫驗收測試（在小邏輯和測試無論如何，它們都會變慢）。 Lean如何通過精益用戶故事進行驗收測試（或BDD測試），達成了什麼共識？
從維基百科引用：
」 ......一個用戶故事是由在一個或多個句子的說明終端用戶或系統用戶的日常或商業語言，它捕捉用戶做或需要做的工作功能的一部分「
在這方面，驗收測試很有意義。驗收測試是需要勾選以滿足用戶故事的「勾號框」。
你所描述的聽起來很像技術性任務。驗收測試在這方面沒有意義，因爲最終用戶無法接受。單元測試和集成測試將更適合這個粒度級別。
所以，當你看一個故事，你可以識別需求的層次結構。程序將要執行的功能需求，功能所需的派生需求以及描述如何執行該功能的服務需求質量。
所有要求都是可測試的。要求的測試是組件測試的總和。只有在每個派生要求和服務質量合格的測試通過時，此測試才能通過。 Derived要求的測試可以是產生新的衍生要求和qos標準或單個測試的節點。測試服務質量通常需要收集性能指標，例如資源消耗和及時性。
例如，你可能會寫的人創造你的服務的用戶測試。
的功能需求是，用戶能夠創建一個帳戶。
部分衍生要求：驗證碼，電子郵件驗證和持久服務器。
的服務質量對於這些需求將進一步描述用戶體驗（驗證碼將有字符4和7之間等）
你可以開始看到這個結構之間的平行和Odedesigne隨着需求在結構樹中擴散。這個想法是，所有需求都有相應的測試代碼，測試代碼作爲整個項目的一種文檔和開發概述。
當你開始給它測試人員的測試代碼的實現提供了補充報告與產品體驗測試人員直接技術指標。
因爲如果你在設計一個音樂流媒體服務，您可以編寫一個測試，說一個用戶的音樂不會跳過，從來沒有超過內存使用閾值的例子。然後通過給用戶提供alpha/beta產品並觀察測試結果，開發人員可以看到他們的軟件在真實世界中的表現如何。
希望考慮在這些方面的測試將幫助你實現的東西:)