聊聊測試開發(fā)工程師的職責(zé)定位問題
發(fā)布時間：2023-08-07 08:49:27
網(wǎng)上有人會把測開定位成為 測試工具開發(fā)，主要是開發(fā)自動化測試工具或平臺，用以幫助手動驗收的同學(xué)提升效率。存在即合理，確實有一些團隊或組織是這樣建設(shè)的。但作為行業(yè)從業(yè)者，我們也應(yīng)該認識到，這樣是不全面的，有誤導(dǎo)之嫌。
現(xiàn)實中的絕大部分測開還是定位在 保障業(yè)務(wù)迭代質(zhì)量 上，因為這才是業(yè)務(wù)最需要的部分，也是最能直接產(chǎn)生價值的部分。而工具開發(fā)，屬于 提效 范疇，當然也需要，但其緊迫性以及價值會因企業(yè)而不同，也會與企業(yè)所屬的發(fā)展階段息息相關(guān)。所以很多時候，工具具體能提效多少，都需要工具開發(fā)者能夠想清楚，甚至要能顯式證明。
也許大家會覺得，保障業(yè)務(wù)質(zhì)量招聘測試就可以了啊，為啥要招聘測開呢？其實這是把質(zhì)量保障這件事想Low了，從 最終服務(wù)于客戶的質(zhì)量 出發(fā)，要想做好質(zhì)量保障真沒那么容易。很多質(zhì)量領(lǐng)域的事情，都不是單純的測試能搞定的，但又是客戶必須的，比如速度，可靠性等。測試僅僅只是質(zhì)量保障的手段之一，還有很多其他的手段也仍然有效。就拿架構(gòu)評審，代碼Review，發(fā)布審核等事項來說，要想?yún)⑴c無疑都需要質(zhì)量同學(xué)對技術(shù)有更深的認知。筆者最近也在嘗試通過發(fā)布審核來把控全局質(zhì)量，所以也非常想看到有更多的質(zhì)量同學(xué)往這方面發(fā)展，大家能彼此探討。
不過，畢竟時代局限性仍在，從事質(zhì)量領(lǐng)域的同學(xué)還是以測試為主。所以，此時如果企業(yè)想招聘一位技術(shù)比較好的測試同學(xué)，她一般JD都會選擇叫 "測試開發(fā)工程師"，因為這樣能更好的匹配預(yù)期。要說明的是，在企業(yè)內(nèi)部其實叫什么真的不重要，也沒太有人關(guān)心，企業(yè)看中的始終是價值產(chǎn)出。私下里，我其實更喜歡QA(Quality Assurance)這個稱呼.因為我會覺得QA包含Ownership意味，寓意我在負責(zé)某件事。而"測開"的叫法感覺跟"開發(fā)"一樣，字面上更像個執(zhí)行者，總是欠缺了那么一點主觀能動性。
另外，當團隊里所有的QA同學(xué)都有不錯的開發(fā)水平時，你會發(fā)現(xiàn)，很多常見的"測開工具" "測開平臺"需求就會顯得不是那么剛需，甚至可能沒必要。比如，相比通過Web或者Excel管理用例，直接用代碼+Github管理對經(jīng)常寫代碼的同學(xué)來說可能更自然；執(zhí)行用例也是，通過命令行，或者Jenkins/Prow，也很方便；另外，Postman可能會用的很少，因為對于經(jīng)常與服務(wù)器打交道的同學(xué)，使用curl會更方便，其也基本夠用；甚或者想搞個簡單的壓測，用系統(tǒng)自帶的AB工具(Apache benchmarking tool)隨手就完成了。凡此種種，筆筆皆是。
說到這里，有同學(xué)可能會問: 測開同學(xué)除了測試任務(wù)，就沒有提效的要求嗎？會不會大材小用？當然不是，在這種情況下，一些提效需求反而可能更具挑戰(zhàn)性。因為這時候的提效目標就不是單指QA了，而是要面向全體工程師，甚至后者優(yōu)先級更高，畢竟群體規(guī)模越大，投入產(chǎn)出比越高。另外就是需求越往上，需求的邊界與傳統(tǒng)的測試會越模糊，與業(yè)務(wù)越直接。比如發(fā)布灰度、質(zhì)量運營、監(jiān)測打點等等，這些系統(tǒng)都與質(zhì)量有關(guān)，測開同學(xué)有能力的話當然也可以上。
總結(jié)來講，對于測試開發(fā)的職責(zé)定位，我始終認為應(yīng)該聚焦在 保障業(yè)務(wù)迭代質(zhì)量，提升迭代效率 上，這點不應(yīng)該變。而更具體的做法我會傾向于宣導(dǎo)：
做業(yè)務(wù)的質(zhì)檢者，關(guān)注檢出率、漏出率，把控全局質(zhì)量，為企業(yè)把好生產(chǎn)交付關(guān)。 做工程研發(fā)專家，保障業(yè)務(wù)迭代規(guī)范，加速迭代效率，關(guān)注軟件工程技術(shù)的研發(fā)角色。
好像看起來挺難的，但不難的話又如何進步？
