什麼時候應該寫BDD測試場景？

Question

我正在調查scrum場景中的BDD測試，並意識到BDD場景比測試更類似於規範。

因此，他們應該在開發人員進行預先規劃之前編寫，以便確定所有功能，以便在該會議中更好地進行估算，優先化等？

Answer 1

一般來說，在Scrum中，您希望用戶故事也滿足條件。意思是，如果滿足這些條件，我將作爲產品負責人，確信故事已完成。

最好由產品負責人編寫這些文件，如果使用Given/When/Then格式編寫這些文件，最好使用它們。這樣，團隊可以根據滿意的條件創建BDD測試。測試通過後，故事就完成了。

產品負責人應該儘可能多地滿足條件，以確認故事已經實施，並且應該在sprint規劃會議上及時準備好這些條件。他們不需要編碼，但應該寫出來，以便團隊瞭解預計完成故事的內容。

隨着事情出現，團隊可能會在衝刺期間添加自己的BDD測試，但直到最初的BDD測試通過後，故事纔會完成。

Answer 2

我希望你提到行爲驅動開發。如果我​​是對的，它是與開發人員，質量保證和非技術或業務參與者進行交互的過程。這也是開發人員代碼的目的和好處。您可以在預先規劃時啓動Scrum場景。

估計和優先排序不在其中。

Answer 3

如果您正在尋找BDD（也稱爲驗收測試驅動開發），您可能願意在Sprint計劃發生之前儘早開始編寫驗收測試。其他一些「更敏捷」的方法傾向於推遲到最後一個負責任的時刻，並且我一直在執教幾個團隊，在Sprint期間，驗收標準隨着時間的推移而逐漸完善。

開發團隊的「測試人員」在準備下一個Sprint（稱爲預測）的積壓工作期間與產品負責人緊密合作，並且在當前的衝刺期間，他們豐富了驗收標準根據採購訂單看是否合適。

這幾乎取決於你如何執行這些測試......如果你能夠自動化，比事情更清晰:-)我們確實廣泛使用Cucumber或Fitnesse來自動化驗收測試，並且正如你對TDD所做的一樣（沒有A），你會在承諾發生之前嘗試做到這一點，至少在基本層面上（你不需要全部定義 - 記住它不應該看起來像一個合同）。

BDD的目標是從行爲角度推動軟件的發展，這應該給你一個關於如何以及何時編寫驗收標準的非常清晰的「方法」。我發現它們與用戶故事的INVEST清單以及Ready for you Backlog的定義非常有用。

HTH ANdreaT

Answer 4

如果BDD你的意思是「行爲驅動開發」，那麼你就可能受到字當頭，「測試」在那裏絆倒。

他們不是測試，即使你會得到免費的測試。如果你認爲它們是測試，你會很糟糕地使用它們。

它們是規格。如果你以這種方式接近他們，你可以看到他們如何適應你的過程。

這取決於你，但是你可以通過強迫自己遠離他們作爲測試的想法而獲得最大的好處，而是將它們作爲規範對待。沒有任何東西可以阻止你誤用它們（作爲測試），但是濫用它們將保證你不會從這種方法中受益 - 而且它是相當可觀的。