對軟件測試團隊「核心價值」的思考

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

一般，軟件開發團隊彷佛幾乎不談論本身的「核心價值」，而針對測試團隊總有對該問題的特有思考是否是折射出了現實的一些情況？由於但凡探尋「核心價值」時，每每意味着價值不夠清晰或者找不許重點。

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

「零和遊戲」之困

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

軟件測試部門的角色一般定位爲「質量衛士」。天然地，他們所發現軟件缺陷的數量和嚴重程度與其績效潛移默化地有着緊密關聯。因而乎，測試工程師爲了體現其價值，但願儘量在缺陷跟蹤系統中新建缺陷記錄。但開發工程師就不幹了，由於缺陷數量一樣能夠做爲考覈指標以衡量其開發質量。進一步咱們有了這樣的工做場景：測試工程師發現問題後，首先與開發工程師進行溝通，在徵得開發工程師的贊成後再新建缺陷記錄（這個過程有時變成了一種博弈，而非真正爲了工做效率）；開發工程師對於測試工程師所發現的問題不是持感激態度，反而認爲他們是在「找麻煩」。因爲「質量衛士」的存在，開發工程師問心無愧、冠冕堂皇地認爲保證軟件質量是測試部門的事。

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

軟件質量的概念

估計沒有人會質疑測試活動自己的價值，其背後的道理恐怕再簡單不過了。但咱們仍需先探討一下什麼是軟件質量（後面簡稱爲「質量」），不明晰這一律念會很難保證測試活動能有的放矢。

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

用戶級的軟件質量咱們能夠經過根據需求文檔編寫的測試用例來加以評估。可是團隊級質量（即軟件設計質量）則很難經過這些測試用例去評估，但軟件缺陷數量卻也能反映出必定的狀況。若是某項目的軟件缺陷數量在至關長的時間內出現幅度較大的波動，這大多意味着軟件設計存在問題，也代表開發團隊並無從根源上解決問題，而是採起了「七修八補」的短時間行爲。另外，從開發團隊是否時常處於「救火」狀態也能很大程度地反映出軟件的團隊級質量水準。

咱們須要測試工程師嗎？

理想狀況下，測試能夠由開發工程師們去完成，由於「他們知道軟件的全部實現細節」，但現實與理想老是存在差距。徹底由開發工程師去完成測試工做存在如下可操做性問題：

1）對開發工程師的能力要求過高。這些傢伙不只要精通編程語言、熟悉業務，爲了測試還得掌握測試理論、測試方法和實施測試所需的腳本語言。要求一旦過高，就容易出現資源稀缺的現象。另外，咱們設想一下，工程師如何才能達到這麼高的要求？學校裏學？仍是工做中學？若是在工做中學，那麼在沒有達到要求前他們在工做中承擔的角色又是什麼？

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

3）開發工程師們經過採用軟件模塊化的方式實現協做，這種情形下必定須要有人從測試的角度去統領整個系統，靠開發工程師本身實在勉爲其難。

面對這些可操做性問題，若是有人還一味地堅持測試工做應徹底由開發工程師完成，那隻能說他在否定社會分工的益處，也極可能是忘記了本身在成長爲「全能選手」前所承擔的角色。

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

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

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

所制定的共同質量目標最好是團隊級別的，由於從開發工程師的角度來看，只有這樣才能保證開發工做按步就班，也意味着他們和公司能從中得到最大的收益。從這個角度說來，測試工程師能夠考慮「我如何幫助改善軟件的設計質量」。這個問題或許太大，對測試工程師的要求也過高（後面咱們還會談這方面的內容），但咱們能夠從「如何保證軟件的可測試性」這種更具備指導性的問題入手。

退而求其次的是，測試團隊與開發團隊共享相同的用戶級質量目標。在這個層面上，測試團隊將發現巨大的發揮空間。好比，測試團隊可否搭建或改善單元測試的平臺，以幫助開發工程師更方便地實施單元測試；又或者可否幫助開發工程師構建持續集成的平臺；等等。

請注意，我並不是主張測試團隊應對開發團隊言聽計從，而是主張測試團隊應使用本身的測試專業知識幫助開發團隊提升開發質量與效率，而非只充當檢驗員的角色。測試工程師必定須要創建團隊的自信：測試是一個專業領域，在質量保證方面咱們有本身獨到的看法，能爲開發工程師提供幫助。

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

現實的無奈

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

回頭看看國內，好象將測試看成比開發次要而非同級。對測試工程師的要求彷佛也沒有開發工程師高，這一點從招聘時碰到某位工程師不適合開發崗位時會考慮他是否適合作測試能夠看出。以個人理解，測試工程師應當是開發工程師出身且水平更高，由於只有水平高了才能對軟件質量有更深入的認識，纔有能力從質量層面貼心地指導和幫助開發工程師的平常工做。

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