這是敏捷開發團隊管理系列的第二篇。（之一）

　　測試團隊的價值

　　這樣看來，敏捷開發的質量保證問題，都被發開團隊解決了，測試團隊的價值何在？

　　這個可以從第一個項目組后來的發展來分析。

　　在整個程序團隊大力保證產品質量的同時，項目組也一點點顯露出一些問題。

　　比如每個模塊的質量都還不錯（有些模塊甚至有一些原始的自動單元測試腳本，每次都能對模塊進行回歸測試），但是整個產品終集成后，是否能如期完成業務要求，卻是未知的。因為各個模塊的測試都集中在各模塊的質量上，對于所有模塊湊在一起的工作結果，卻無法驗證。而且在原來的團隊體系下，師徒團隊各自負責一個模塊，居然沒有人為此負責。

　　所以我們很需要一個人來團隊里邊，把整體集成及集成后的測試抓起來。這種工作，與其說是傳統的面向質量的測試工作，不如說是一種面向驗證的測試工作。是只要能告訴我們集成在一起是可以工作的，目的達到了。

　　測試團隊的“發展”

　　這里邊有很多戲劇性的過程。

　　首先過了一段時間，測試經理（雖然測試組當時只有2個人）想招幾個人，原因是要寫很多介于代碼和腳本之間的語言，來仿真業務。

　　為什么說是仿真？原因是我們的產品之外，還有一個“訂戶管理系統”，這個系統的數據，是我們的業務。但由于他們部門的產品也在開發中，所以我們不得不先手工形成一些仿真業務。

　　這個問題，后來被開發組的人解決了。因為他們編寫了一個文本的腳本語言，只需要手工寫一些人眼很容易看懂的英文縮寫和數字，能仿真一些業務。

　　這個腳本語言及其編輯、調試器后來越做越復雜（但因為開發它的開發人員對內部業務很熟悉，所以只花費了前后2周左右的時間），能夠自動運行、單步運行、設置斷點調試。

　　有一次，兩個測試人員在2天里用腳本編輯器編寫了144個測試用例，每個測試用例包含5～128個購買和分組行為，來仿真和測試他們認為可能的各種排列組合。這些測試用例不是我們常常遇到的寫在Word或Excel里邊的那種，而是用那個腳本編輯器打開，按F5，會自動執行并吐出結果的那種。

　　這個工作如果由人力來完成，無論是編寫測試用例，還是執行以查看結果，都是幾乎不可想象的。

　　兩個測試人員有一次希望大干一番，以便驗證一些不是有意構建的用例是否可以通過測試。但終結果是，這個編輯器和調試器后來被發展成能自動生成測試用例，乃至將用例發給真實機頂盒+IC卡系統和一個仿真的機頂盒+IC卡系統（一個友好的可以F5調試的VC++系統），如果發現區別則自動記錄，并繼續產生下一個用例。

　　這段代碼因為走的時候沒有留下文檔而失傳了，不過在7年后的一次老同事聚會中了解到，團隊在后續的幾年中按照這個原理，把很多不同層次的硬件（數字電視里邊的，大約有10種之多，個個都是黑底綠字乃至干脆沒有屏幕的，非常難纏）都做了純軟件仿真，每個模塊做好了，都可以扔進去和仿真硬件集成一番，這些工作大大縮減了后真槍實彈時候經常出現的莫名其妙的問題，大大縮減了集成和測試時間。

　　這些程序人員的工作成果，保證了在團隊有25人的時候（峰值曾經到達30人），只要兩個測試人員能完成整個系統的功能測試，這個團隊發展十分“緩慢”；但是從另外一個角度看，那些為測試團隊編寫測試代碼的人，到底算是開發人員還是測試人員呢？

　　啟示

　　一個的團隊，應該受到關注的應該是質量的高低問題、集成的效率問題、功能驗證的效率問題……這些有人買單的問題，而不是開發與測試的分工、如何明確責任、如何對雙方進行績效考核等沒人買單的問題。

　　所以盡管2001年那個時候敏捷開發的概念還不太清晰，但是本著“無我無人”的精神（詳見般若敏捷系列之四），很自然地創立了自己的敏捷方法。

　　這件事情讓我回憶起近正在與很多業界人士合著一本“敏捷開發案例集”，中間有一個討論時：“到底什么案例是敏捷案例，什么案例不是敏捷案例？”

　　后的結論是：“第一個很松：大致有點和敏捷沾邊行；第二個很嚴：開發方法一定要被證明是的”，換言之如果大家對的開發方法視而不見，而到處找“敏捷開發方法”，是舍本逐末了。

　　下一篇，將談及開發團隊和測試團隊的組織關系問題，比如專業的測試團隊好，還是分散到開發團隊中的測試團隊好，抑或還存在其他的組織結構等。