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

測試團隊的價值

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

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

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

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

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

測試團隊的“發展”

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

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

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

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

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

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

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

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

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

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

啟示

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

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

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

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

?

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

轉載于:https://www.cnblogs.com/wodeyitian/archive/2011/12/17/2459914.html

總結

以上是生活随笔為你收集整理的敏捷开发团队管理系列之三：程序与测试团队II的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。