歸檔場景和重溫故事

Question

在處理大型複雜的應用程序時，我想知道我們應該在哪裏存儲場景以記錄軟件的工作方式。

當我們討論現有功能的問題時，很難看到我們已經完成了什麼，很難用諸如TFS等scrum工具回顧。我們有一些測試，但這些對於產品所有者來說是不可見的。
我們是否應該考慮抽出一些廣闊的故事/場景列表，修改/更新，或者這不是敏捷。

除了代碼，一些單元測試，一些測試用例和一些過時的用戶指南，我們沒有關於軟件如何工作的記錄。

Answer 1

我們傾向於使用我們的自動驗收測試來證明這一點。當我們處理用戶故事時，我們也開發了自動化測試，這是我們完成定義的一部分。

我們使用SpecFlow進行測試，它們被寫爲Given，When，Then便於閱讀和理解並可與產品所有者共享的場景。

這些測試增加了很多價值，因爲它們是我們的自動化迴歸套件，因此迴歸測試更快更容易，但是由於我們在開發新故事時不斷更新它們，因此它們也可用作系統工作方式的文檔。

您可能會發現看看幾個基於示例規範的博客很有用，這實際上就是我們正在嘗試做的事情。

我發現在過去有用的幾個環節是：

http://www.thoughtworks.com/insights/blog/specification-example

http://martinfowler.com/bliki/SpecificationByExample.html

Answer 2

除此之外，我們還用於文檔維基測試。特別是REST API記錄了請求/響應示例，還有其他軟件行爲（長時間討論的結果，難以記憶的東西）。

Answer 3

由於您希望能夠匹配您對正在運行的軟件所做的操作的描述，因此聽起來您應該將其與軟件一起放入版本控制中。從文檔/目錄開始，然後根據需要添加詳細信息。我經常這樣做，而且它是正常的。如果你想使這個網絡可用，然後建立一個Web服務器的地方每隔一段時間檢查一次文檔，並將文檔根目錄指向工作副本docs /目錄。