大家熟悉的測試工作可能是，接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試、提bug、回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是，測試同學非常被動：當需求質量、開發質量差的時候，你只能被動接受，結果就是你會進行漫長痛苦的測試過程以及因為質量差導致上線延期；同時很有可能乙個線上問題裸奔了幾個月，最後是業務方先發現才排查到是bug導致，由於影響時間過長給公司造成的損失巨大，還被質疑為什麼這麼明顯簡單的問題上線之後沒人發現。
但是如果你實踐了測試左移以及測試右移，你就能擁有更多的主動權，你有更充足的時間進行測試，同時不會像之前因為質量差風險高每次都延期上線，並且產品的質量也能***。為什麼測試左移和右移能做到這點呢，我們先了解一下什麼是測試左移和右移。
測試左移
測試左移就是在提測之前已經介入了測試。在需求評審時不只是了解需求，更是要去評估需求的質量，分析需求的合理性以及完整性。在開發階段時也要參與設計方案的設計，了解開發的實現方式。因為很多開發可能只對他負責的那一塊熟悉，作為測試需要評估改動範圍以及是否有遺漏的模組和系統。測試還可以通過提供測試案例或者自動化測試指令碼的方式給開發，讓開發在設計時考慮地更全面，同時方便開發在coding時進行自測，有助於提高產品質量，畢竟越早發現問題，解決的成本就越低。測試同學還需要不斷地培養產品、開發同學的質量意識，同時提供必要的技術支援，協助產品、開發更好的進行測試，比如公共用例、測試工具、測試指令碼。這樣，你會發現提測的質量大大提高了，原本提測後你還需要花一天的時間進行冒煙測試，現在都可以有時間進行更多的探索了。
測試右移
測試左移和測試右移
前幾天看爬文的時候看到了這篇 shift left and shift right the testing swing 裡面描述了一些測試左移和測試右移的思路和方法，覺得有一定的啟發，可以分享一下。作者站在專案或者產研發負責人的角度闡述了自己團隊在敏捷及devops中的測試實踐，根據功能和產品所處的...
測試左移與右移
大家熟悉的測試工作 也是傳統的瀑布式 是接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試 提bug 回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是 測試左移以及測試右移，能夠讓測試擁有更多的...
測試左移與右移
我們大家熟悉的測試工作可能是，接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試 提bug 回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是，測試同學非常被動 當需求質量 開發質量差的時候，你只...