談談我的第三次測試經歷及總結
從17年到22年，中間經歷過兩家公司，第一家也就一年的樣子，更多的成長以及感觸還是第二家，之前一直拖著沒寫，這次總結下。
從零開始階段
適應期
我是作為專案第一個專業的測試進入的，雖然有一個前端開發轉的測試，這時候專案開發團隊也就十來個人，專案也是初始孵化，僅小範圍的試執行。快速熟悉專案後，就準備上手了，雖然需求變動頻繁，也額外有其他專案的測試需求，好在業務邏輯也簡單，測試設計彷彿也變得沒那麼重要。
這個時期主要的思考是：
- 如何快速的融入團隊，熟悉業務？
- 沒有相關的規範下，思考如何開展測試活動？
- 沒有相關的文件下，手動摸索業務功能及邏輯流轉。
規範嘗試期
初步完成幾版需求過後，針對目前的一些團隊問題，就開始準備一些規範避免，包括測試計劃、測試用例、測試上線報告等等，但大部分還是以效率為準，也是老大要求的。測試執行階段，有問題扯著嗓子吼一聲，bug找的快改得也快，大概是開發不願被二次提名吧，畢竟大家工位就兩三排，心知肚明。
這個時期會面臨一些問題：
- Bug逃逸率較大，也就是質量不高。
- 沒有沉澱相關的文件，問題的溯源畢竟麻煩。
- 技術基礎建設薄弱，技術價值體現單一。
- 臨時需求互動，大家回切換精力較大。
零到一階段
專案變動期
大概過了3個月，上層決定把專案遷至杭州作為獨立產品運營，於是伴隨著專案人員變動，第一批過去了部分開發，導致測試溝通成本加大。
杭州初建的團隊也開始融入，包括新技術leader、新的測試及開發人員，帶來新的規範開始融合，比如重要的測試報告。我是第二批過去的，這時杭州團隊已經出具雛形。
這個時期的主要工作：
- 專案調動帶來的思考
- 測試規範學習期，主要是來自新技術Leader的建議
- 新入職測試人員的任務安排與分配
產品基礎建設嘗試期
在我沒去杭州時，已經跟杭州的團隊交流協作過了，來到杭州後，測試活動也照常進行，僅是大部分陌生的臉。這時主要是基礎架構升級，從之前的php開發轉為java開發，於是新的測試需求出現了，系統剝離與重構，此外產品也迎來了2.0時刻，雖然產品設計依舊在矇頭亂撞。
最主要的感受就加班的日子越來越多了，但是當時氛圍很好，並不覺得累。而且作為公司老人，自然而然擔負起了測試組長的角色。
這個時期的主要工作：
- 業務測試的比重佔80%。
- 測試團隊的擴招，準備相關的面試資料。
- 新人的帶領培訓，包括考核的制定。
- 測試團隊的磨合，討論並整合相關測試規範。
- 技術部leader的指導，落地行業內相關的解決方案，比如靜態程式碼檢查、線上問題收集工具等。
- 跨部門的協作，相關會議明顯增多，產品及需求越來越複雜。
開始積極團隊建設，相關的建設如下：
產品基礎建設變動期
就這樣大概忙碌到年底的時候，部門leader決定後端團隊由java轉為go開發，其中有很多原因：一是java後端沒有好的架構師角色，欠下很多技術債；二是本身技術棧也是go，也考慮到未來的行業規劃等等，不過java整體還沒穩定，又提出轉型，這注定是個痛苦且艱難的過程。
而我們質量團隊也得為這個決定付出巨大的努力，一直持續到第二年年底，整個java後端才逐漸更替完成，而原有java服務改造工作還沒開始，慶幸是我們的大前端團隊比較穩也很給力，不然質量團隊真的入不敷出了。
這個時期的主要問題：
- 測試業務的比重佔70%，雖然大Leader總是強調作為TeamLender不要陷於具體的業務。
- 後端語言的更換導致的人員變動，需求斷層。
- 團隊氛圍比較低迷，工作感受很累。
- 測試的基礎建設實施基本沒有增長。
團隊建設緩慢，如下：
產品基礎建設穩定期
在後端go語言替換java接近尾聲時，也是我來杭州的第三年，這時，團隊成員也趨近穩定了，產品的業務方向也比較明確了，部門協作規範也清晰了，大家都鼓勁一起衝，團隊建設也有比較明顯的提升，測試團隊被定位為效能提升角色，年度目標是技術能力對標杭州第二梯隊公司，而我們測試組也開始提升整體實力，包括組內知識庫的沉澱，組織組內python學習，也包括介面自動化與UI自動化的推動。
後面經過雙十一的事故，效能的基礎建設也提上了日程，不過由於很多原因，3年的職業生涯也到此結束。
這個時期的主要成果：
- 測試規範更清晰更明確
- 測試知識庫的沉澱
- 測試人員的開發能力提升
- 專項測試的落地
- 效能思想的轉變，併產出了多個效能提升專案
團隊建設稍有起步，如下：
------------------------------------------------------------ 三年總結 ------------------------------------------------------------
再總結之前，我們先提一個問題：面對軟體日益複雜的情況下，如何能更好的保障質量？
你可能會說：測試左移？測試右移？TDD？迴歸測試？自動化測試？敏捷測試？混沌測試？AI測試？
相信大家很熟悉這些詞，這些手段或者過程也或多或少經歷過，雖然看起來簡單，但每塊展開來就東西多了。按照目前的經歷，要知道公司發展的每個階段都會有對應階段的問題，有能解決的，也有解決不了的，能解決的問題也不一定當下會解決。
還記得臨走前與領導吃飯，他提了一個關鍵詞優先順序：效率>質量>體驗。他還說最看重一個人解決問題的能力，是啊！解決問題的能力細化下來太多太多了。
囉嗦了這麼多，我給到的回答包括三部分：
- 一是測試的全流程建設，從提出需求到被實現，到最後運營的每個階段都要做質量保障的手段，這可以根據公司與業務的實際情況做調整，大廠的質量體系、保障大盤看看就好。
- 二是定位好團隊角色，是效能提升還是質量保證為主，我知道基本大部分的測試資源都很緊張，或者說整個技術團隊的資源都比較緊張，但業務方就是要快。這時就是效率>質量，就要分析測試重心，找到質量的平衡點，減少不必要工作；如果是質量>效率，就要嘗試各種手段，圍繞如何找到更多的問題，多做一些探索性的工作。
- 三是要深入業務，這是老生常談的問題，也是最容易忽視的問題，一句話做技術是為業務服務的，業務做不好，一切都不免談。
這是我多年工作來的感受，也歡迎大家拍磚，也許後面會有新的認識，堅守測試，一起為測試行業的發展努力吧。
很喜歡下面一句話：
軟體測試的真正價值並不體現在從程式碼中找出了多少缺陷，而是發現設計和程式設計人員解決問題方法上的侷限，思路中的狹隘和技能方面的不足。——快排演算法託尼·霍爾