【敏捷迭代式開發中的測試】第二篇：夥伴．品質．溝通

從前一篇文章中：『【敏捷迭代式開發中的測試】第一篇：有關測試的真實劇本序章』提及了測試人員在敏捷開發流程中所扮演的角色及人員素質。在這一篇文章裡，將進一步細化說明測試人員的關鍵工作成功因素及工作目標。

一、夥伴意識

相較於瀑布式開發中，將測試列為開發後的工作環節之一，在迭代式開發中測試人員的角色顯示與開發與需求方都更為親暱地多。

瀑布式開發將「需求」發展至「產出物」的一系列工作事項，以功能區分及線性流程串起來。需求蒐集及分析、系統分析、系統設計、系統開發、系統測試，及至驗收，都可能是以一個實體部門進行負責。完美的情形下，每個環節的交付物是如鎖練般地被串接，也或者像是線上地圖系統可以從整個地球的五大洲圖逐一細化到指定國定、城市、鄉鎮、道路、巷弄一樣的能不斷的 refine。

當然，這種完美並不存在，所以對於每個環節的部門或人員來說，上游的產出物或導致本身環節的產出物不正確、與需求目標產生偏離、或是根本無法產出。除非，在這個環節去償還上一個環節所欠的債！分析的債、設計的債、溝通的債、文件的債…債的類型很多，共同之處在於：還債的人大多和欠債的人不一樣。

還債行為會導致組織內的夥伴意識崩潰。因為欠債的人有時甚至不知道欠下債的人是自己，還進一步地怪罪幫忙還債的人為什麼無法如預期地進行產出。如果下游將欠債的事實告知上游，就會變會上游必須暫停手邊的工作、去償還自己積欠的債務，而此時就代表：在該時間點，上游原先預定的工作將產生延遲，而下游突然間變得沒事做。

在這種總體時間及產出物於各環節中不平衡的狀況下，責任的歸屬問題、專案成敗關鍵的茅頭就會很人性地讓整個組織容易處於敵對、相互隔離、彼此試探…等內耗。那循環儼然是不良的、參雜了很多人性及政治因素，一旦與風氣、權力個人相結合後，就會成為組織中極為難解的問題。

迭代式開發，更仔細地說，是「重複漸增」式的系統演化方式，要求的是測試人員成為開發人員的夥伴。當開發人員專注於功能的構建時，測試人員使用外部環視的角度為其提示品質相關的問題，讓開發的進展與問題的浮現腳步一致。這樣的好處是：問題在剛開始產生時，多半很容易修正！而測試人員應該是開發人員的另一雙眼鏡，讓開發人員隨時能輕易地改正自己犯下的錯誤、沒正視到的盲點。

也由於測試人員能隨時協助開發人員關注品質，所以開發人員能更專注、更放心地把心力放在功能的實踐上，而不需自己三不五時地必須去確認、質疑某些質量需求、思考是否要對現有的設計想法進行修正。

記得，測試人員應該和開發人員是好夥伴，就像左右手一樣，應該能共同地把好東西做出來！

二、品質

相較於專注於如何把真正的需求進行蒐集、分析、系統化、及系統分析、設計及整合的人員來說，測試員會幾近參與上述所有流程，因為他們需要做整體的檢視，並且條列出符合環境限制及真實需求的品質定義才行。在執行層面，不論他們做了什麼，都是為了維護該品質定義清單中的每一項。

測試人員在品質這一項工作上的探究，基本上和架構師的工作是有層次相關的。首先，除了要留意 context limits (這包括客戶及自身組織)及功能性需求 (functional requirement)外，品質的另一個名字還可以稱之為「非功能性需求」(non-functional requirement)。

依需求/產出物的要求、不同行業別、組織限制的情形下，所需留意的非功能性需求有很大的不同。但是大抵來說，要有以下起碼的認知：非功能性需求的各項是經常彼此產生矛盾、需要權衡的。例如：易用性和安全性。要有什麼樣的取捨？這可能由客戶決定、依環境限制進行妥協，或是由架構師視系統的長遠目標進行權衡。但是，真正在整個流程中不斷關注非功能性需求決議、並保持該決議沒有被違背的人，就是測試人員。

有關非功能需求有哪些？筆者偷個懶，給個 wiki 的定義，讓讀者去發揮吧！

http://zh.wikipedia.org/wiki/非功能性需求


三、溝通

當我們發現測試人員，依上述所言，需要：

1. 全程參與需求至產出的所有流程。
2. 需要瞭解客戶、架構師對品質的主要訴求、取捨以及環境上有哪些限制？
3. 必須和開發人員 (乃至上述的所有角色) 都要能成為良佳的夥伴關係。

那麼，測試人員在溝通上的能力就應該備受重視！

測試人員要能和開發人員進行：

1. 有效的溝通：提供明確的輸入及輸出限制及回應品質。
2. 加分的溝通：隨時讓開發人員了解其忽略或沒留意到的地方，讓開發人員對整體需求有更具體的方向感。
3. 體貼的溝通：能理解開發人員的難處，並將其反應在品質控管的結果中。

測試人員要能和需求方協議出合理的品質要求，就必須進行：

1. 務實的溝通：環境的限制、技術的範圍、資源的有限性都是必須務實的原因。當其他人過於關注需求的想望與功能的實現時，測試人員要能即時提出務實的中斷點，讓全場的人得以回到地面上再進行討論。
2. 雙贏的溝通：由於測試人員能站在務實的角度去觀察系統整體的進展，所以也有提出讓系統需求及開發方創造雙贏的餘裕及職責。

綜合上述，測試人員在溝通上的能力及個性或其它天賦上的要求是不低的。你身邊已經有一個好夥伴了嗎？那麼，就恭禧你了！