傳統TDD與接受TDD

Question

我正在討論介紹接受TDD和傳統TDD概念的配備TDD的書。現在我想問一些對這兩個概念相當熟悉的人 - 誰是Acceptance TDD測試用例的作者？開發人員，質量保證專業人員還是業務分析師？我不認爲開發者會成爲一個很好的人來寫驗收測試嗎？你是否同意我的觀點 ？

Answer 1

簡短的回答：

您可以找到這兩本書所有的答案多：

The cucumber book

Specification by example

這些書是要拯救你在ATDD/BDD這個課題上花了很多時間。

龍答：

理想情況下，你希望他們的樹上討論接受審覈規定合作。

有時它不是很實際，所以你可以先讓廣管局處理所有顯而易見/不含糊的接受標準。

然後，對於非顯而易見的問題，您需要QA/BA/DEV一起工作，以便他們可以就困難部分達成共識。瞭解對方的最佳方式是使用示例/具體用例場景，這些場景將作爲您的接受標準。這種合作需要發生，以便您也有機會找出如果BA或QA只是自己工作而錯過的東西。我們的目標是限制返工，因爲我們有時會忽略驗收標準中的重要內容。

將QA/DEV/BA引入同一個房間可能會被視爲昂貴的活動，但它確實是一個非常強大的組合。 BA知道這個領域真的很好，QA知道什麼可以打破，DEV通常在QA和BA之間，但是也知道所有的技術可行性。當這些樹一起工作時，你可以確定他們會找出可能錯過的東西或消除複雜東西中的歧義。簡而言之，如果這個功能非常簡單，那麼你不需要那樣做，而且BA可以自己工作。但是，如果你有一些複雜的功能，你必須讓這三個人一起合作來限制返工。

無論你選擇做什麼，更重要的是要有一個時機，這些接受標準可以通過它們的樹來討論和檢查，以便每個人對需要做什麼有共同的理解。