研發效能-測試要做的一些內容

這兩年研發效能非常的熱門，也正好負責這塊算是跟上了行業快車，但是到底怎麼做研發效能，或者測試在研發效能裡面能做啥。在我接觸的團隊和客戶中往往都是迷茫或者談這個問題尚早的。

管理目標
一談敏捷、DevOps、研發效能，管理層的第一感覺是節能增效，而參與的大家也會這樣思考，但是落地後發現各種技術債。最終落地失敗，又為了形式而形式，為了流程而流程，搞的身心俱疲。

研發技術債
為何要轉型敏捷，為何要談研發效能，本質就是從過去到現在一直在亂做，到了無法解決後期問題的時候了。前幾年偷懶留的坑，現在填不上了。對於大多數情況下，如何有效的做版本管理，框架模式，測試的快速反饋及容器化轉型，就這點東西入門已經可以搞死大多數的公司了。例如做個持續釋出，有多少公司能夠接受在生產上做一套備份伺服器的藍綠部署或者逐步灰度的問題。這也是全鏈路效能測試做的糾結的原因之一。先推動自動化運維再推動自動化測試吧。

測試技術債
關於測試的技術債，都2020年了，能做自動化，能做好自動化，能想明白自動化測試怎麼做的也沒多少人。個人非常反對測試人員自己玩一套和研發分離的自嗨模式，我也承認Py在做入門的時候有很多優勢，但是你不能只懂怎麼測，不懂為什麼要這樣測或者怎麼更有效的測試。不和配合研發做好單元測試，內建質量，談啥研發效能。

當然做研發效能未必非要正規，有個符合精益思想的持續改進思路就行了，做任何事情需要量化，從公司到個人，研發效能就是那個投資回報比的參考資料。我做啥，用多少代價，能換回多少利益，這是永遠不會變的道理。至於大家要做啥？公司缺啥就做啥，做啥有價值就做啥也沒毛病，至少在初期，先把怎麼測試的基本能力玩熟，玩的很6了，那麼才能解決持續測試本身的成本問題吧。

在研發效能下測試應該做的：
有敏捷理念，跟得上公司文化及流程的更新，具備例項化使用者需求，同步持續測試，一定的生產管理能力，這是入門級別的要求。