如何度量測試開(kāi)發(fā)的價(jià)值產(chǎn)出？

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

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