前幾天無意中看到了TesterHome發起的《2023年度軟體質量保障行業調查報告》，文中提到了幾點調查結果和分析結論讓我很感興趣。針對這份調查報告，我想就下述三點結論談談我的一些理解和思考。
一、測試參與度分析
在這一調查報告結論中，提到了需求評審、測試計劃和測試評審是整個測試流程中的核心環節。當然除了這三項，靜態程式碼掃描和專案迴歸覆盤的佔比也不低。
印象裡在前幾年，特別是2015-2019年，大家更多的認為在測試過程中技術實踐更重要，比如自動化測試。而近幾年大家開始迴歸本質，從更底層來思考質量保障和業務之間的關係。
對此我是這樣理解的：國內的IT行業發展至今，主要經歷了三個階段，用幾個詞語概括則是按部就班、百花齊放、方法沉澱。
第一階段：按部就班，大體對應04-10年。這個階段國內的IT網際網路技術領域並沒有太多創新和應用空間，基本是照搬國外的方法來開展技術工作。
比如瀑布模型，比如QPT/LoadRunner等商業工具，比如用Jira進行需求和專案管理。雖然在整個研發測試流程中，也會遵循各種規範，但測試在其中的左右，更多的是QC角色，即質量檢測。
這個過程中研發和測試的關係，更像是流水線的上下游，大家各行其是，沒有很好的配合。
第二階段：百花齊放，大體對應12-18年。伴隨著移動網際網路的爆發，業務場景越來越複雜，線上流量訪問壓力更大，系統架構也變得越來越複雜。
業務的複雜性和多樣性對技術的要求更高，與之對應的則是各種各樣的技術探索和工程實踐落地，比如測試崗位出現了專職的自動化測試、效能測試、測試開發等崗位。
第三階段：方法沉澱，大體對應19-22年。網際網路狂奔猛進的勢頭放緩後，大家開始降本增效，更追求投入產出比，從以前的粗放式實踐迴歸到思考本質。
且經過多年的技術實踐和各種分享，大家逐漸積累了很多方法論，也有了更有普遍性認同的一些最佳實踐，比如測試左移右移，而測試的角色也逐漸演變為質量保障(QA)。
要做好質量保障，就不能只在流程中所謂的測試環節下功夫，大家開始思考影響質量的因素並開展對應的防護措施。比如需求分析和評審，比如更合理可行的測試實施計劃，比如系統上線後的覆盤歸因和持續迭代最佳化。
二、阻礙測試進度因素分析
影響測試進度的因素有很多，且大多數因素並不歸屬於測試環節，只是這些因素帶來的風險在測試環節開始集中爆發，這也是為什麼很多測試同學自嘲自己就是背鍋的由來。
我們都知道質量是設計出來的，而不是測試出來的，測試動作更多的是驗證研發實現的軟體產品是否符合產品預期設計的各種標準。
如果產品需求在一開始定義不清楚，要求不明確，研發對需求的理解有誤，會進一步影響到編碼實現的功能，最後就是開發和測試的相愛相殺，提不完的BUG，測不盡的問題。
當測試同學開始肩負起質量保障的責任時，為了解決需求不明確的問題，就要主動去推進需求評審，提前暴露風險，將問題扼殺在初始階段。
為了使研發的編碼質量更好，就有了技術方案評審、靜態程式碼掃描、和研發show case以及冒煙提測的各種實踐。
每個專案或者版本迭代都有交付的deadline，需求和研發階段預防還不夠，還要想辦法提升測試階段的效率和質量，隨之就有了自動化測試、精準測試、端到端測試各種方法和實踐。
不僅如此，產品釋出後的線上質量更能引起技術同學敏感的神經，因此線上巡檢、業務防資損、完善的監控體系和應急響應機制以及專案覆盤也成了質量保障的必備措施。
除了上述的部分因素，還有諸如需求頻繁變更、專案排期壓縮、測試資源不足、測試資料混亂、測試環境不穩定等因素也是影響測試進度和質量的真兇。
三、哪些原因導致了質量問題
上面第二部分提到了很多影響測試進度的因素，其實這些因素也是影響質量提升的罪魁禍首。
畢竟資源和精力有限，在倒排期的deadline和各種因素影響下，測試同學只能儘可能去保證核心的部分，加上各種各樣的複雜因素和意外，質量的提升只能說是任重道遠。
從軟體工程的角度來說，軟體產品質量有一個不可能三角，即成本、範圍和時間最多滿足兩項，如下圖。
降本增效大環境下，為了控制成本，自然而然投入的資源就降低了，如果能保證需求範圍明確和時間因素不變，那質量理論上來說是可控的。
但在實際工作場景中，頻繁的需求變更和不明確的需求依然是頻發現象。
與此同時，很多時候影響質量的因素是歸於管理者而非執行者的。
如果上述的不可能三角都可以滿足，那一切都好說，但很多時候，管理者為了保住自己的飯碗或者獲得晉升，會透過各種OKR/KPI來影響執行者，而OKR/KPI往往在落地執行過程中扭曲變形，最後一地雞毛。