測試策略制定(20090915)

今天和ThoughtWorks顧問重點討論了一下測試。
目前的階段開發、測試都在思考一些準備性的工作。道雨兄一直對於可測性需求關注度比較高，
之前和他在一個組裏進行培訓時，已經多次在不同場合提到這個話題，可以感受到他的疑惑。
因此在當下思考測試策略的時候再次浮出水面也就不足爲奇了。

當客戶需求將開發日程表排到溢出的時候，突然冒出來的可測性需求宛如寂靜的會場上大笑數聲，
讓大家都有些尷尬。排了也痛，不排也痛，被砍的可能性還挺大。這是現狀。
出現這樣的反應首先要解決一個問題，測試和開發的關係到底應該怎樣定位？

討論過程中提到一個模式就是現實版存在構造一個與開發對立的測試部，達到在質量上充分發揮
監督審查的效果。開發與測試吃同一個績效餅，對方吃多了自己就吃少了，所以二者相互較勁。
那麼在這個問題上，“可測性需求”必然淪爲犧牲品，可以說是零和遊戲，雙輸。
“就算站在世界頂端，如果沒有人陪伴，又怎樣？”


在敏捷的實踐要求上，測試開發要混在同一個Team中，隨着產品的生長一起完成每個迭代。
當所有迭代完畢，一個瓜熟蒂落的產品就可以交付客戶了。(理論上是這樣，但是我估計最後應該
還是要追加一輪轉測試，纔會是比較放心些的，算是吃之前洗下蘋果吧)。這個流程和我們的
傳統理念上有質的差異。

差異點就是測試是開發工作的一部分，是迭代中若干角色的一種，枚舉比較能夠表示出這個關
系的平等性。
typedef enum
{
Developer,
Tester,
Analyzer,
} RoleOfIteration;

Tester這個角色在迭代中完成“開發階段的測試工作”，是保證我們“製作”的產品符合質量
要求的“必須”的工序，是“必須”的。不是可選的。這部分工作目前是測試部在承擔。

而“洗蘋果”是“測試階段的測試工作”，是用來站在客戶的角度來“確認”我們提供的產品
確實沒有問題。僅僅是確認一下，因爲我們的要求高。是可選的。如果我們種蘋果沒有打農藥
施化肥，摘下來蘋果不洗就應該可以吃。

將這兩個作用清晰後，Tester的定位就明確了。“必須的”，Must，“我們一個Team的”。
在這個前提下，整個迭代Team需要爲Tester開展當輪迭代工作分配資源，當輪的可測性需求就
是其中之一。在整個Team的範圍內可以分配資源去完成“可測性需求”，也可以不完成。這是
Team對自己行爲的成本收益的判斷後做出的決定。是否會因此產生“技術高利貸”也由當事人
自己承擔。這裏需要提及的是沒有可以一刀切的必殺技，不同的可測性需求成本的差異非常大。

基於這個理念，再次回到測試策略的制定問題上來。由於每輪迭代的Story不同，對應的策略
有可能會不同：也許手工就夠了，也許需要開發個可測性“後門”才能自動化，或者直接用現成
工具就可以製作測試套。這樣在迭代0之前就僅僅能夠制定一些粗略的測試策略。細化的必須在
每輪迭代中才能完成。

在ThoughtWorks中，測試的工作大部分用自動化來解決。Tester的工作更象我們這裏的解決方案
測試，最終洗一下蘋果，所以規模上沒有那麼大。我們的組織結構是否適應模式的變化，需要更
多人的體驗才能感知。

還有很多內容，有點收不住，太晚了，今天先寫這些。