測試人員的煩惱，測試是處於研發流程末端，因此前期的各種問題都會影響到測試。如何打破這種困境，已經成為測試人員迫在眉睫的問題。
作為測試應該有責任去監督開發，產品等各個環節，以免對測試端造成影響。建立測試左移的思想，從需求階段開始思考，如何對整個流程質量的保障。
所謂測試左移，就是控制上游質量，提前規避風險。如何做好測試左移，可以從下面幾個方向切入：
需求的頻繁變動，我想研發和測試都是非常苦惱的一件事情，而且維護成本也是非常大，如何提高需求的質量已經刻不容緩！
在需求評審前，產品一般都會提前給出本次評審內容，這個階段可以要求測試和開發提前對需求有個了解和思考，並且針對一些不確定或者存在問題的地方做好記錄，待正式評審的時候跟產品經理一一確認，保證需求的質量和穩定。
針對提出的需求問題的價值，可以進行分級，一旦被產品採納，則可以給與對應人一定獎勵，提高大家對此環節的積極性。共同來保障需求的質量。
可以安排測試或者研發來進行需求講解，同樣提公升大家對需求的理解，當然這可能會導致里程碑的延後，可根據情況進行選擇。
如果測試人員有能力，可以參與研發的設計評審和資料庫評審，因為測試是對業務最熟悉的，如果存在業務上的設計缺陷，能提前規避。
在需求拆解過程中，可以先把業務流程圖畫下來，然後用思維導圖列出本次迭代的測試點。雖然會帶來額外的工作量，但是我覺得短期可能工作量有，但是後期的收益也是可以預見的。
業務流程圖有助於對需求和業務進行深入思考；
測試重點和業務流程圖作為知識文件沉澱，有助於新入職員工快速融入團隊，開展工作；
流程圖和列重點更直觀，後期評審用例也有提效作用；
用例寫完後，可以先組織測試人員內部互查，達到查缺補漏的效果。
產研測三方評審，同樣可以設計用例反講，但是也是根據團隊情況而定，評審過程中挑重點，非重要的可以一帶而過，提高評審效率，會議越拖收益越低。
對於開發提測，我們可以設立提測准入條件。
選取本次迭代重要的測試用例給開發自測；
分發給開發的用例必須自測通過；
提測後，測試冒煙通過；
滿足以上條件後，才能進入系統測試。
首先我們要設立上線的質量標準，比如：
不能帶著嚴重bug上線；
測試用例必須全部通過；
一些輕微bug經過商議允許上線，必須在下一迭代作為高優先順序進行處理；
做好上線方案；
測試左移和測試右移
前幾天看爬文的時候看到了這篇 shift left and shift right the testing swing 裡面描述了一些測試左移和測試右移的思路和方法，覺得有一定的啟發，可以分享一下。作者站在專案或者產研發負責人的角度闡述了自己團隊在敏捷及devops中的測試實踐，根據功能和產品所處的...
關於「測試左移」 「測試右移」
作者新建了qq群 460430320，供大家交流測試心得 培訓機構勿進 另外，還會不定期上傳測試資料，也歡迎您共享測試資料。之前寫過該話題的部落格，但最近在看一些大佬聊天的時候，感覺get到了一些新的思路，拿過來，分享給大家。1 測試左移 右移，可以針對測試團隊來說，左移就是盡早的參與專案，從需求階...
測試左移與右移
大家熟悉的測試工作 也是傳統的瀑布式 是接到專案後參與需求評審，然後根據需求文件寫寫用例和準備指令碼，等開發提測之後正式開始測試 提bug 回歸，測試通過後就結束了，專案交給運維上線，之後投入下乙個專案繼續重複這樣的流程。這樣的流程看似沒什麼問題，但缺點是 測試左移以及測試右移，能夠讓測試擁有更多的...