要求TDD的可追溯性？

Question

它總是說要求應該是可追蹤的，但是當我們談論敏捷開發時，這是非常困難的。 我的問題是如何在敏捷中管理需求可追溯性（或需求變更管理），特別是測試先行開發或測試驅動開發？

Answer 1

在TDD或BDD（行爲驅動開發）中，您的需求被捕獲到您的測試中。

您可以將您的測試與實際需求（更多TDD模型）進行映射，或者實際將您的測試用作產品需求（更多BDD模型）。

有關BDD和測試功能作爲要求可以做什麼的很好的示例，請查看Ruby/Rails世界中的簽出RSpec和Cucumber。

在FDA管理的環境中工作，對質量工程負責，我可以告訴你TDD/BDD非常適合FDA審覈員正在處理的模型。

BDD的模型，可以讓你追蹤通過：

• 要求 - >測試
• 測試 - >實施
• 實施執行 - >測試結果

Answer 2

可能是我缺少的東西，但TFD或TDD是在單元測試級別。你所指的是在我看來由Traceability matrix和/或acceptance tests管理。

Answer 3

當需求發生變化時，測試會發生變化。請記住，測試是有效的文檔和需求規格說明。因此，這種變化是無縫的。

例如：需求更改導致測試期望更改，這反過來導致代碼更改。

Answer 4

敏捷可追溯性是非常很難開始，目前有很多工具聲稱通過記錄用戶故事來提供可追溯性，或從用戶故事或從測試產生的TDD中生成需求。

點，當我們考慮所有的敏捷方法不必強調文件（閱讀Agile Manifesto。所以，我不知道雅居樂將如何具有可追溯性，並與它的核心原則簡化。

Answer 5

最近發現了一個traceablity，在線需求管理工具[http://code.google.com/p/ultimate-trace/ Ultimate Trace]試用一下，它爲我們節省了大量的可追溯性，

Answer 6

重新閱讀宣言「，它更重視四種說法中的右半部分，但要注意它寫着」左邊有價值「。這意味着文件本質上不是邪惡或禁止的，它們應該是謹慎的並且不應該推翻工作的真正目的。話雖如此，電子追蹤工具多年來一直存在，一些更優雅和一些絕對的野獸。從測試案例回溯到定義它們的故事很重要，尤其是當系統進入R & M.否則，隨着系統的增長，您需要權衡追查系統文檔以追查系統組件。可追蹤性可以通過命名約定，配置/代碼基線工具的某些功能，測試套件工具或RTM來處理。老舊的學校方法是電子表格（請撕開我的手腕），但我們現在已經走了很長一段路。