對軟體測試團隊“核心價值”的思考

之前曾寫過《軟體品質管理的困境與對策思考》，在其中談到開發部門與品質管理部門（QA）應形成一個有“交集的雙環”而非“啞鈴型”組織，也指出軟體品質管理應重實踐輕量化，其目標應是協助工程師改善工作習慣和提升開發環境的效率。那時並沒有認真地思考過測試團隊的核心價值，直到讀到@段念-段文韜老師的《測試團隊與咖啡店》。

通常，軟體Team Dev似乎幾乎不談論自己的“核心價值”，而針對測試團隊總有對該問題的特有思考是不是折射出了現實的一些狀況？因為但凡探尋“核心價值”時，往往意味著價值不夠清晰或者找不準重點。

以我過去一直從事軟體開發相關工作的經曆來看，測試團隊對於“核心價值”的特有思考的確存在其必然性。探討其根源讓我們從一個“遊戲”開始。

“零和遊戲”之困

多數軟體企業都設立了開發與測試兩個部門，且兩個部門屬於企業價值鏈中的兩個有互動但又獨立的節點。在企業中只要是個部門就大多存在績效考核問題，似乎只有這樣才能證明該部門存在的必要性。

軟體測試部門的角色通常定位為“品質衛士”。自然地，他們所發現軟體缺陷的數量和嚴重程度與其績效潛移默化地有著緊密關聯。於是乎，測試工程師為了體現其價值，希望儘可能在缺陷跟蹤系統中建立缺陷記錄。但開發工程師就不幹了，因為缺陷數量同樣可以作為考核指標以衡量其開發品質。進一步我們有了這樣的工作情境：測試工程師發現問題後，首先與開發工程師進行溝通，在徵得開發工程師的同意後再建立缺陷記錄（這個過程有時變成了一種博弈，而非真正為了工作效率）；開發工程師對於測試工程師所發現的問題不是持感激態度，反而認為他們是在“找麻煩”。由於“品質衛士”的存在，開發工程師心安理得、堂而皇之地認為保證軟體品質是測試部門的事。

不難發現，這樣的體制下其實創造了一個“零和遊戲”。這個遊戲給我們帶來的困境是：測試部門的“贏”（發現了更多的缺陷）意味著開發部門的“輸”（開發品質不佳）；反之亦然。總而言之，兩個部門很難達成共贏，有時甚至出現各自為政的極端狀況。

軟體品質的概念

估計沒有人會質疑測試活動本身的價值，其背後的道理恐怕再簡單不過了。但我們仍需先探討一下什麼是軟體品質（後面簡稱為“品質”），不明晰這一概念會很難保證測試活動能有的放矢。

我在《專業嵌入式軟體開發》一書中曾指出，品質是分級的，它包含使用者和團隊兩個層級。簡單說來，使用者級的品質由軟體缺陷去反映，而團隊級的品質反映於Team Dev能否按步就班地實施開發工作而非經常處於“救火”的“緊急狀態”，團隊級的品質是涵蓋使用者級的更高形式。我在該書中還指出，軟體設計是品質之本，只有高質的軟體設計才能保證團隊級的品質，並最終長期給我們帶來使用者級的品質。這些主張很明確地表示，品質首先由軟體開發工程師負責。

使用者級的軟體品質我們可以通過根據需求文檔編寫的測試案例來加以評估。但是團隊級品質（即軟體設計品質）則很難通過這些測試案例去評估，但軟體缺陷數量卻也能反映出一定的情況。如果某項目的軟體缺陷數量在相當長的時間內出現幅度較大的波動，這大多意味著軟體設計存在問題，也表明Team Dev並沒有從根源上解決問題，而是採取了“七修八補”的短期行為。另外，從Team Dev是否時常處於“救火”狀態也能很大程度地反映出軟體的團隊級品質水準。

我們需要測試工程師嗎？

理想情況下，測試可以由開發工程師們去完成，因為“他們知道軟體的所有實現細節”，但現實與理想總是存在差距。完全由開發工程師去完成測試工作存在以下可操作性問題：

1）對開發工程師的能力要求太高。這些傢伙不僅要精通程式設計語言、熟悉業務，為了測試還得掌握測試理論、測試方法和實施測試所需的指令碼語言。要求一旦太高，就容易出現資源稀缺的現象。另外，我們設想一下，工程師如何才能達到這麼高的要求？學校裡學？還是工作中學？如果在工作中學，那麼在沒有達到要求前他們在工作中承擔的角色又是什嗎？

2）當開發時間很緊的情形下，要讓開發工程師同時關注設計品質和測試品質幾乎不大可能。現實中，能顧及前者就算是很出色的開發工程師了。此外，這種不可能不是單方面由開發工程師決定的，而是有太多的專案管理團隊總有“壓縮時間能促使Team Dev不散漫”的錯誤認識，而沒有意識這種認識驅使的行為所帶來的副作用——影響了軟體的設計品質。

3）開發工程師們通過採用軟體模組化的方式實現協作，這種情形下一定需要有人從測試的角度去統領整個系統，靠開發工程師自己實在勉為其難。

面對這些可操作性問題，如果有人還一味地堅持測試工作應完全由開發工程師完成，那隻能說他在否認社會分工的益處，也很可能是忘記了自己在成長為“全能選手”前所承擔的角色。

綜上所述，我們需要有測試工程師與開發工程師共同努力以實現品質目標，而這也意味著測試工程師是有價值的！

測試工程師貢獻價值的方向

測試工程師要很好地貢獻價值，首先要與開發工程師有共同的目標。也就是說，開發與測試團隊先要把品質目標變成“我們的”，而不是“你的”或“我的”，否則很難打破“零和遊戲”所帶來的困境。就這一點，我完全認同@吳穹老師在他的《測試的雙重目的性及理性品質觀》一文中所倡導的“只有將開發與測試完全地混合在一起，不分彼此，才能夠真正獲得好的品質，不應試圖去隔絕開發與測試團隊”。換句話說，開發與測試團隊在組織架構上的關係要做適當的修正以支撐這種主張，否則它是阻礙測試團隊輸出價值的第一個巨大障礙。

所制定的共同品質目標最好是團隊層級的，因為從開發工程師的角度來看，只有這樣才能保證開發工作按步就班，也意味著他們和公司能從中獲得最大的收益。從這個角度說來，測試工程師可以考慮“我如何協助改善軟體的設計品質”。這個問題或許太大，對測試工程師的要求也太高（後面我們還會談這方面的內容），但我們可以從“如何保證軟體的可測試性”這種更具有指導性的問題入手。

退而求其次的是，測試團隊與Team Dev共用相同的使用者級品質目標。在這個層面上，測試團隊將發現巨大的發揮空間。比如，測試團隊能否搭建或改善單元測試的平台，以協助開發工程師更方便地實施單元測試；又或者能否協助開發工程師構建持續整合的平台；等等。

請注意，我並非主張測試團隊應對Team Dev言聽計從，而是主張測試團隊應使用自己的測試專業知識協助Team Dev提高開發品質與效率，而非只充當檢驗員的角色。測試工程師一定需要建立團隊的自信：測試是一個專業領域，在品質保證方面我們有自己獨到的見解，能為開發工程師提供協助。

總的說來，測試團隊需要站在測試專業領域的高度為Team Dev提供指導與協助，也只有這樣開發工程師才能感受到“我們擁有同一個品質目標”。這種觀念我想也正是@段念-段文韜老師在《測試團隊與咖啡店》一文中想強調的。另外，Google讓測試團隊隸屬於Engineering Productivity這一FA（Focus Area）或許也正是出於這一考慮的吧！

現實的無奈

讀者可以從網上搜尋《Google是如何做測試的》這個系列翻譯文章，其中談到了Google是如何組織測試的，裡面的內容很值得我們學習與思考。總體說來，我覺得Google對於測試工程師和測試開發工程師的要求相比國內我所見到的更高，且其中開發測試工程師的作用非常關鍵，他們review設計、審查代碼的品質與風險、重構代碼使之具備更好的可測試性、編寫單元測試和自動化測試架構等。

回頭看看國內，好象將測試當作比開發次要而非同級。對測試工程師的要求似乎也沒有開發工程師高，這一點從招聘時碰到某位工程師不適合開發崗位時會考慮他是否適合做測試可以看出。以我的理解，測試工程師應當是開發工程師出身且水平更高，因為只有水平高了才能對軟體品質有更深刻的認識，才有能力從品質層面貼心地指導和協助開發工程師的日常工作。

測試團隊對“核心價值”困惑的存在，很大程度上是由於國內對測試的重視不足，強行割裂開發與測試兩個活動而導致的。其所帶來的更大危害在於，測試人才缺乏一定的梯度。