(一)敏捷測試指引

原文：Agile Testing Directions – Introduction （Brian Marick）

        在XP Agile Universe上，兩個人-或許更多-告訴我說，我在敏捷測試的發展方面貢獻不夠。我在過去5年里花了太多的時間說我不知道敏捷測試會怎樣，沒有足夠的指示和指導?！暗亲屛覀兛纯?，也許我們可以找到?！彼麄兛赡苁菍Φ?。因此我讓本文作為這方面的一個起點。

        我先重申一些普遍的概念區別，以作為起點。

        如果你聽到別人在談論敏捷項目中的測試，問一下那些測試是面向業務的還是面向技術的，會對你有很大的幫助。面向業務的測試是你可以用一個業務專家感興趣的術語來向他描述測試。如果你通過電話描述測試回答了什么問題，你可以使用業務領域的術語：“如果你支取超過你的賬戶余額的現金，系統是否會自動給予你一筆與超出部分等額的貸款？”

        面向技術的測試是你使用程序員的領域的術語來描述測試：“不同的瀏覽器會通過不同的方式實現Javascript，所以我們測試產品是否能在最主要的瀏覽器上工作?！被蛘撸骸叭绻脩粲涗洸淮嬖?，PersistentUser#delete不應該執行?！?/P>

（這些分類有著很多模糊的界線，例如，選擇測試哪個瀏覽器配置，部分是業務決定。）

        問一下正在討論測試的人，他們希望測試支援編程還是批判產品。對于“支援編程”，我的意思是程序員把測試作為編程的主要組成部分。例如，一些程序員編寫測試用例來告訴他們下一步應該寫什么代碼。通過編寫那些代碼，他們改變一些程序的行為。這些更改之后通過運行這部分的測試來保證他們修改的是他們需要的。運行其它的測試來確保更改的行為不會影響其它不需要更改的部分。

        批判產品的測試則不是專注于編程方面。而是在已完成的產品上查找發現產品的不足之處。

        如果把這兩類區別放到一起，就得到下面的矩陣圖：

        接下來，我會談談這個矩陣的每個區域，我關于它們的發展的預測。

        左邊是偏向“支援編程”的測試，右邊是偏向“批判產品”的測試。但是兩種測試的意義和內涵存在很大的不同。

        對于支援編程，測試主要作為準備和保證。你通過寫測試代碼來闡明關于問題的思考。你把它作為說明性的例子來描述代碼應該怎樣做。幸運地是，它同時是活躍地檢查代碼的說明性例子，即重新保證。這些測試也會找bug，但是那是第二目的。

        在另一方面，測試是關于暴露主要錯誤和遺漏。這里，測試的原義就是關于bug。有其它的意義，但是首要的意義是最主要的。（很多測試員，尤其是最好的測試員，在他們的身上已經融入了那些詞語的內涵。）

        我想做個嘗試。如果我們在矩陣的左邊不使用“testing”和“test”這些詞語會怎樣？如果我們把它叫做“checked examples”（檢查例子）怎樣？

        設想兩個XP程序員坐在代碼前面。他們開始構建一個例子來說明下一步要做什么。他們會檢查，在代碼還沒寫之前。（如果寫了，那是很特殊個別的情況。）他們編寫代碼。檢查例子是否運行正確，其他例子也保持正確。然后繼續下一個例子用于展示下一步應該做的事情。

        替換詞語有意義嗎？是否只是文字上的替換而已？你做一些嘗試，然后回答這些問題吧。嘗試經常使用“example(例子)”，經常使用讓它聽起來不會感覺很奇怪?，F在，當你坐在代碼前面時，是否根本改變了你的觀點？是否有了一些不同：在你向客戶要求一個例子，而不是一個測試時。加上一些形容詞：example(例子)是否看起來更具激發性、更生動、更有深刻內涵？與強大的測試存在怎樣的區別？（“強大”作為附加給測試的典型的形容詞。）測試人員在XP項目中，每個人都在制作例子，沒有人做測試，這樣是否看起來更輕松些？

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