一、開發提測時的提測質量同時受多個因素的影響
1、項目的規模。這里可以理解為，項目的規模越大，通常合作的人越多、需要考慮的邏輯越多/越復雜；項目的規模越小，相比之下，開發人員需要考慮的邏輯也比較容易把控。因而，規模較大的項目的提測質量，通常比小規模項目的提測質量要差一些。

2、開發同學的自身項目經驗。日常的項目跟進中，對于類似的一些需求，通常經驗豐富的開發同學的提測質量會好很多。
3、涉及業務的復雜程度。如果一個業務涉及的模塊較多，關聯的第三方業務較多，那么無疑這個業務修改時，出問題的概率也會越大。
4、開發周期的長短。開發周期通常需要技術團隊來評估，但如果為了趕項目，而壓縮開發周期時，通常會給提測質量留下隱患。
上面的因素會直接或間接影響提測質量，但由于這些因素屬于客觀因素，每個團隊、項目都會有所不同，且不太受人為因素的影響，因而這些因素不是本文討論的重點。那有哪些事情是可以提前做的，來確保提測質量呢？
二、確保提測質量該如何做?
確保提測質量的目標是在提測時，確保項目達到一定的質量水平。因而，拋開那些影響提測質量的客觀因素外，我們需要做些事情，來確保提測時的質量水平，讓提測質量盡可能逼近上線質量。
　　1、明確項目流程。這里的項目流程，不僅僅是提測流程，也包括需求評審、測試用例評審、技術評審、風險分析等等，確保項目有任何實現風險、提測風險時，能快速周知到項目成員，方便大家一起齊心協力解決，而不是一個問題的block，直接阻塞的項目的順利進行。
2、合理的需求評審。這里的需求評審的目標，是力求項目各個角色成員對需求的理解一致、對需求的風險點、影響范圍等理解無歧義。避免技術實現與需求不符的情況發生。

詳細的用例評審。這里的用例評審，是為了確保場景覆蓋，以及再次確認項目各個角色成員對各個需求點理解一致
3、技術評審。QA同學與開發同學一起技術評審，可以提前預防/發現技術設計、技術實現方面的問題
4、靜態代碼掃描。確保代碼的實現規范符合團隊要求，保證代碼的長期可維護性適時的人工Code Review。這里可以針對代碼實現邏輯、規范做具體檢查，提前發現問題，也可以使用工具，如sonar等。
5、明確的冒煙用例。冒煙用例是提測前，需要開發同學必須自測通過的用例。冒煙用例最好自動化進行驗收，避免因為開發同學執行的問題，導致測試執行不徹底
6、公認的提測流水線。提測時，可以將靜態代碼掃描、自動化冒煙測試、自動化主流程回歸測試進行集成，讓開發同學提測前進行自檢。
7、QA提前介入測試。QA提前測試本質上已經進行測試了，但由于尚未正式/全面進行測試階段，因而一定程度上，也可以確保提測質量