如何度量測試開發的價值產出？

每到年底的時候，不管是個人還是團隊，總是避免不了要對這一年的工作成果進行總結和匯報。而對于測試開發崗位來說，通常會面臨一個共性的問題：做了這么多事情，究竟產出了多大的業務價值？
在很長一段時間內，我對這個問題也是非常困惑。困惑的原因倒不是覺得工作內容沒有價值，而是對于測試開發類的工作，通常沒有明確的業務需求方，對于工作成果度量也沒有統一的方式。
為什么測試開發崗位會面臨這個問題呢？
這應該和測試崗位的職責和工作內容有很大的關系。關于測試開發工程師的定義，在《Google測試之道》一書中已經有了很全面的解釋，我也很是認同。測試開發工程師（SDET，Software Development Engineer in Testing）首先應該是開發角色，只是相比于業務開發工程師，他們的目標用戶更多的是公司內部的測試人員（也包括其他崗位的項目組成員），而核心工作內容就是提供通用測試技術解決方案，開發實現測試工具或平臺，協助測試人員更好地完成測試工作和項目交付，而效率和質量也是他們最為關注的方面。
從崗位職責和工作內容可以看出，測試開發通常不會直接參與業務交付，并且他們通常也不會隸屬于具體的項目組，因此對于他們的工作到底產出了多少實際的價值收益，在上面的領導或老板看來就不是那么明確，最終他們面臨價值產出度量的問題也就在所難免了。
本文就圍繞測試開發價值產出度量的問題，談下我的一些思考和建議。
何為業務價值？
我們總是在說業務價值，那業務價值究竟指的是什么？為什么同樣是寫代碼開發系統平臺，大家通常會覺得開發電商、售后平臺是產出業務價值，而開發測試工具平臺就不產生業務價值呢？這種想法是否正確？
其實當我們回歸商業的本質，就會得知問題的答案了。對于商業公司來說，通常是以盈利為目標的，而為了達成這個目標，就需要通過業務手段，對用戶提供價值，最終獲得用戶的買單。從這個角度來講，決定是否對公司產生業務價值與崗位類型無關，也與開發實現了什么系統或平臺無關。例如，對于提供測試類服務的公司或項目組來說，例如聽云、WeTest，開發出的測試工具平臺就直接面向客戶，并以此獲得盈利，那么參與該類項目的測試開發工程師就直接產出了業務價值。而在絕大多數非測試服務類商業公司中，測試工具平臺更多是提供一種輔助手段，幫助項目組更好更快地完成業務需求交付，而并不直接創造業務價值。當然，這個問題不僅在測試開發崗位上存在，對于某些開發崗位也是同樣存在的，例如開發公司內部即時通訊工具、流程審批工具、消息網關、中間件等等。
因此，對于測試開發崗位來說，不必揪著“業務價值”不放，我們完全可以從其它角度來對工作成果產出進行度量和展現。
節省人天數？
那要使用什么度量指標呢？
在很多時候，大家可能會想到使用“ 節省人天數 ”這樣一個指標。因為測試開發的主要職責之一就是提升測試效率，那如果能度量出在使用測試工具平臺后減少了多少人力投入，那么就能很好地體現該工具平臺的價值。
那么要怎么計算“節省人天數”呢？之前我們使用過的方式如下：
統計出項目的回歸測試場景，以及在固定周期內的發版次數（假設為N次）；
估算出通過人工去執行這些測試場景的耗時（假設為M人天）；
統計出工具平臺執行測試的耗時（通常該耗時可忽略不計）；
那么節省的人天數就為：N * M
乍一看，這個思路沒啥問題，也能計算出具體的節省人天數。但在實際項目中嘗試運作之后，我們發現該計算方式存在比較大的漏洞。
例如，某測試工具平臺在 A 項目組投入使用后，通過計算，每月節省了人力10人天?？墒?，A 項目組的發版頻率并沒有改變，項目組人員編制也沒有縮減，甚至根據招聘需求，人員編制還出現了增長的情況。那在這種情況下，通過計算得出節省的人力去哪兒了？
對此我們并不能給出很好的回答。事實上，測試人員借助測試工具平臺從之前的重復手工工作解放出來后，他們可能花了更多的時間在需求分析上，也可能花了更多的時間在測試策略設計上。這都是我們所期望的結果，但問題在于，這些內容我們并不能很好地去統計和量化。這也就導致我們統計出的“節省人天數”缺乏說服力。
而且從更宏觀的層面來看，度量項目組的質量情況時，更多是會關注交付效率和線上質量（漏測率）兩個維度。交付效率，可以通過“交付需求數/投入人天數”進行計算，而線上質量（漏測率），可以通過“線上bug數/測試發現總bug數”得出?？梢钥闯?，線上質量（漏測率）與“節省人天數”基本沒有關系，而交付效率方面，除非項目投入人天數真的減少了（通常不大可能），那么交付效率也很難通過“節省人天數”提升。

原文轉自：http://debugtalk.com/post/SDET-Value-Measurement/