敏捷測試指引(4)- 用面向業務的例子支援項目組

　　敏捷測試指引(4)- 用面向業務的例子支援項目組  軟件測試

　　為了幫助討論和理解，我把“敏捷項目中的測試”這一主題分解成4個區分的主題。今天，我講一下我們怎樣使用面向業務的例子來幫助和支援整個項目組的工作(不僅僅是程序員)。

　　我指望項目例子做三件事：激發程序員寫出正確的代碼，促進技術專家與業務專家之間的對話，幫助業務專家更快地在產品中實現可能的特性。讓我們一步步來分析他們。

　　激發出正確的代碼

　　這是測試標準的驅動(或例子驅動)設計從內部接口到整個產品接口的直接推導。為了添加一個新的功能特性，先用1個或多個例子來說明它應該怎樣工作。然后程序員編寫代碼來匹配那些例子。編寫和維護例子直到需要的代碼都得到了。然后功能特性也就完成了(到目前為止)。

　　雖然推斷是直接的，但是我們在得到細節之前還有一段路要走，在充分理解實踐之前。我在下面會講更多關于這方面的內容。

　　促進項目交流

　　把例子仍過墻給程序員并期待他寫出正確的代碼與仍給他需求文檔一樣是行不通的。程序員需要上下文、背景和關于默認慣例的一些知識。他們通過與業務專家交流得到那些東西。例子可以改善交流，通過提供一些東西給大家討論。它們把討論具體化。

　　例子可以提供顯著幫助的地方，我想，是得出一個公共的詞匯表。我喜歡這個想法：領域方面的術語應該通過轉化到代碼中的對象來使其“具體化”。不是幼稚地按“寫出業務領域并在名詞下面劃橫線”的面向對象的設計方式，而是用Eric Evans的領域驅動設計(Domain-Driven Design)的更完善的方式

　　因此我們必須有一個對領域知識的理解從模糊到具體的過程，轉化到0和1的過程?？雌饋砝邮且粋€中間步驟，逐漸讓知識不模糊的過程。但是，使用例子來指引程序員，還有很多需要學習和研究。

　　讓可能發生的更加明顯

　　我們希望業務專家在他們意識到產品通過A的方式做了B，通過X的方式做了Y，因此有必要做一些新的Z，這些他們以前沒有想到的事情的時候，發出“啊哈!”的聲音。我們也同樣希望項目組的其他人有類似的表現，這樣他們可以向業務專家提議一些東西。簡而言之，我們需要創造力。

　　可能最佳的釋放創造力的方式是讓你親手編寫軟件并測試。但是另外一種方式是解釋例子給其他人聽。是否曾經在找bug方面存在困難，然后在開始解釋你的代碼給別人聽的時候蹦出很多錯誤?對于我來說，在寫用戶文檔的時候也會有類似的效果：我使用例子來解釋軟件背后的基本概念，它們是如何組合在一起工作的。我會經常發現它們不工作。與碰到bug的感覺是一樣的，雖然我要解釋的可能不是一個真正坐在我前面的人，而是一個假想的讀者。

　　因此，我們創建例子和討論例子的方式可能會加速產品的進展。

　　我下一年專注的幾個研究方向中的其中一個就是面向業務的例子。我已經準備好了$15000用于調查能很好地使用它們的機構。如果你知道有這樣的機構，請聯系我。在調查了他們之后，我希望能講關于下面的一些故事：

　　1、 關于例子的進度的故事。什么時候創建它們?在程序員開始編碼之前創建了多少例子?什么例子最先創建?

　　2、 關于人們圍繞例子的交流的故事。誰參與了?交流的形式是怎樣的?誰把例子寫下來?業務專家來寫的時候是怎樣的?程序員來寫呢?測試人員呢?(當不同的人之間切換時人們注意到什么了?)在把例子轉換到代碼的過程中例子變化的情況是怎樣的?

　　3、 關于面向業務的例子和面向技術的例子(單元測試)之間的交互的故事。程序員在什么時候、怎樣把注意力從一個轉到另外一個的?面向顧客的例子是否經常檢查?例子是否會從一個分類轉到另外一個分類?

　　4、 關于面向業務的例子影響設計和代碼結構的故事

　　5、 關于FIT的故事。對于什么樣的系統最合適?FIT最好的一個特性之一是它鼓勵把說明性的文字環繞著例子 – 大家怎么利用它呢?當人們從其他方法(用腳本語言編寫例子)轉移到FIT的時候，學到了什么東西?而轉向其他方向的人們學到了什么?當開發一個項目的詞匯表的時候FIT和腳本語言比較起來會怎樣?

　　6、 關于推動代碼的例子(“...這里是功能X的另外一個重要的方面”)和排除bug的例子(“…不要忘記產品要在這種情況下工作”)之間的平衡的故事。怎樣的bug需要預防，怎樣的bug應該留給產品批判的階段(矩陣表的另外一半)?(參見Bill Wake的"generative" and "elaborative" tests。)

　　7、 關于檢查性例子與變化檢測者之間的區別的故事。在面向業務和面向技術方面是否存在不同。

　　只有當我們把這些故事都收集起來之后，關于面向業務的例子的實踐才能被很好地理解，才能成為慣例，就像面向技術的例子的實踐一樣。

原文轉自：http://www.anti-gravitydesign.com