敏捷測試指引（4）-用面向業務的例子支援專案組
陳能技
2007-9-24
原文：agile testing directions – technology-facing programmer support（brian marick）
為了幫助討論和理解，我把「敏捷專案中的測試」這一主題分解成4個區分的主題。今天，我講一下我們怎樣使用面向業務的例子來幫助和支援整個專案組的工作（不僅僅是程式設計師）。
我指望專案例子做三件事：激發程式設計師寫出正確的**，促進技術專家與業務專家之間的對話，幫助業務專家更快地在產品中實現可能的特性。讓我們一步步來分析他們。
激發出正確的**
這是測試標準的驅動（或例子驅動）設計從內部介面到整個產品介面的直接推導。為了新增乙個新的功能特性，先用1個或多個例子來說明它應該怎樣工作。然後程式設計師編寫**來匹配那些例子。編寫和維護例子直到需要的**都得到了。然後功能特性也就完成了（到目前為止）。
雖然推斷是直接的，但是我們在得到細節之前還有一段路要走，在充分理解實踐之前。我在下面會講更多關於這方面的內容。
促進專案交流
把例子仍過牆給程式設計師並期待他寫出正確的**與仍給他需求文件一樣是行不通的。程式設計師需要上下文、背景和關於預設慣例的一些知識。他們通過與業務專家交流得到那些東西。例子可以改善交流，通過提供一些東西給大家討論。它們把討論具體化。
例子可以提供顯著幫助的地方，我想，是得出乙個公共的詞彙表。我喜歡這個想法：領域方面的術語應該通過轉化到**中的物件來使其「具體化」。不是幼稚地按「寫出業務領域並在名詞下面劃橫線」的物件導向的設計方式，而是用eric evans的領域驅動設計（domain-driven design）的更完善的方式
因此我們必須有乙個對領域知識的理解從模糊到具體的過程，轉化到0和1的過程。看起來例子是乙個中間步驟，逐漸讓知識不模糊的過程。但是，使用例子來指引程式設計師，還有很多需要學習和研究。
讓可能發生的更加明顯
我們希望業務專家在他們意識到產品通過a的方式做了b，通過x的方式做了y，因此有必要做一些新的z，這些他們以前沒有想到的事情的時候，發出「啊哈！」的聲音。我們也同樣希望專案組的其他人有類似的表現，這樣他們可以向業務專家提議一些東西。簡而言之，我們需要創造力。
可能最佳的釋放創造力的方式是讓你親手編寫軟體並測試。但是另外一種方式是解釋例子給其他人聽。是否曾經在找bug方面存在困難，然後在開始解釋你的**給別人聽的時候蹦出很多錯誤？對於我來說，在寫使用者文件的時候也會有類似的效果：我使用例子來解釋軟體背後的基本概念，它們是如何組合在一起工作的。我會經常發現它們不工作。與碰到bug的感覺是一樣的，雖然我要解釋的可能不是乙個真正坐在我前面的人，而是乙個假想的讀者。
因此，我們建立例子和討論例子的方式可能會加速產品的進展。
1、關於例子的進度的故事。什麼時候建立它們？在程式設計師開始編碼之前建立了多少例子？什麼例子最先建立？ 2、
關於人們圍繞例子的交流的故事。誰參與了？交流的形式是怎樣的？誰把例子寫下來？業務專家來寫的時候是怎樣的？程式設計師來寫呢？測試人員呢？（當不同的人之間切換時人們注意到什麼了？）在把例子轉換到**的過程中例子變化的情況是怎樣的？ 3、
關於面向業務的例子和面向技術的例子（單元測試）之間的互動的故事。程式設計師在什麼時候、怎樣把注意力從乙個轉到另外乙個的？面向顧客的例子是否經常檢查？例子是否會從乙個分類轉到另外乙個分類？ 4、
關於面向業務的例子影響設計和**結構的故事 5、
關於fit的故事。對於什麼樣的系統最合適？fit最好的乙個特性之一是它鼓勵把說明性的文字環繞著例子 – 大家怎麼利用它呢？當人們從其他方法（用指令碼語言編寫例子）轉移到fit的時候，學到了什麼東西？而轉向其他方向的人們學到了什麼？當開發乙個專案的詞彙表的時候fit和指令碼語言比較起來會怎樣？ 6、
關於推動**的例子（「...這裡是功能x的另外乙個重要的方面」）和排除bug的例子（「…不要忘記產品要在這種情況下工作」）之間的平衡的故事。怎樣的bug需要預防，怎樣的bug應該留給產品批判的階段（矩陣表的另外一半）？（參見bill wake的"generative" and "elaborative" tests。）
7、關於檢查性例子與變化檢測者之間的區別的故事。在面向業務和面向技術方面是否存在不同。
只有當我們把這些故事都收集起來之後，關於面向業務的例子的實踐才能被很好地理解，才能成為慣例，就像面向技術的例子的實踐一樣。
敏捷測試指引（5） 用面向業務的例子批判產品
敏捷測試指引 5 用面向業務的例子批判產品 陳能技2007 9 24 原文 agile testing directions business facing product critiques brian marick 為了幫助討論和理解，我把 敏捷專案中的測試 這一主題分解成4個區分的主題。今天，...
用Visual Studio實踐敏捷測試（二）上
本文的第一部分 上 下 著重介紹了測試人員在敏捷開發過程中，需要完成的一些測試準備工作。對於讀者來說，這些工作項可能會比較陌生，但在敏捷開發中卻對保證開發的質量和速度起到了很重要的作用。在這一部分中，我們將進入大家較為熟悉的實際測試階段，為大家介紹測試任務的執行以及bug的管理。在整個敏捷軟體開發流...
用Visual Studio實踐敏捷測試（二）下
無論採用何種測試形式 執行何種測試任務，都會產生一系列的bug。而開發團隊需要乙個健全的bug管理的機制。一般來說，乙個bug的生命週期大致要經過如下幾個過程 圖4 bug的生命週期 這裡大多數的階段都比較易懂，需要解釋一下的可能就是triage過程。bug在建立出來以後，首先要經過triage小組...