排主計劃時，UAT一般只預留1-2周時間，且遇到趕進度需調整主計劃時，壓縮的往往是測試時間。一是侯世達定律作祟，大家想着萬一uat順利呢，一週用戶測試、一週改bug，時間足夠了；二是從整個項目交付來看，測試顯的“不重要”，開發完一個功能、接口，體現的是實際進度變化，無法縮減，否則系統少功能，是顯性取捨。其實在制定計劃，包括做計劃調整時，憑經驗大家都知道要給uat留夠時間，或緩衝時間，但往往只有到了測試階段時，纔會提出。是個有意思的現象，因爲給領導彙報時，也有底氣，已經是長征終點前的最後幾步了，從項目組角度是可以按期上線的了，但爲了測試充分些，提高用戶體驗度，提升上線成功率，適當延長uat階段。對於項目組也要交差，屬於不可見風險，誰知道uat碰到這些問題，客觀面對。
測試分爲單元測試、系統測試、集成測試及驗收測試，逐級漏斗形攔截缺陷。S1項目資源緊張，產品團隊內部測試不充分，要由現場交付團隊找bug，畢竟是交付團隊在面對客戶，不想問題在客戶面前集中爆發，只能辛苦交付了。
測試資料包括測試計劃、培訓資料、測試腳本、測試問題清單及測試報告。
測試應廣泛邀請業務參與，雖然實際只有小比例參與。收集測試人員、部門、測試模塊，用以提前配置測試賬戶及權限。提前發出測試安排，註明每個模塊的培訓時間。
培訓資料往往是通用功能幻燈片，結合系統演示講解。需把控時間按照測試安排進行，否則易陷入指導業務操作或回答業務細節問題上。培訓應錄屏保存。測試階段的關鍵干係人，是關鍵用戶。顧問應兼具教練的角色，對關鍵用戶進行個性化輔導，對業務關鍵用戶培訓，使其成爲“內部講師”。還有個說法，叫“漣漪型培訓”，關鍵用戶-種子用戶-終端用戶。
若是大型系統的培訓，往往分模塊、多輪進行，可包括項目管理培訓、項目小組關鍵用戶培訓及最終用戶培訓。其中項目管理培訓和項目小組專精培訓將由顧問負責，最終用戶培訓用“Train-the-trainer”的培訓方式，即由“內部講師”負責。
測試腳本，包括測試數據（註明測試時要填寫的數據，否則可能信息傳輸失敗或校驗報錯）、測試腳本、測試通過報文或截圖、測試失敗報文或截圖。測試腳本提供需測試的場景、功能路徑、功能描述、測試步驟、操作描述、期望結果。
問題清單，包括：模塊、問題屬性、等級、描述、提出人、提出日期、狀態、處理方法、實現方式、實際完成時間、處理人。問題屬性包括功能問題、需求問題、數據問題、操作問題、樣式問題。
收集測試問題時，應按照部門或模塊指定唯一負責人對接。既可以把控問題/需求提出的嚴謹性，確保業務是有認真思考後提出的。也可以平衡部門內部的分歧點，消除內部需求不一致性。
測試問題的關鍵，是對於優先級的定義。高優先級爲影響業務流程，必須在上線前解決。中、低優先級則允許上線後迭代優化，只要承諾解決即可。而判定哪些爲高優先級，則需要業務方、項目組及顧問共同討論。有的高優先級問題，評估結果是目前無法實現，或需要變通方案，或需要一定時間解決，需達成一致。這也是Go/No-go meeting的決策依據。
需與業務、顧問提前確定某些假設條件，如以下情況，測試仍會被認爲是成功的：應用程序功能完備，但個別使用者感到不習慣；測試中出現的問題不是業務藍圖的範圍，而是業務藍圖簽字確認後提出的對藍圖方案範圍有實質變更的新建議或新要求。
根據問題解決情況，安排迴歸測試。
測試報告，包括測試安排、測試結果統計及結果分析，說明缺陷修復率、影響流程的高優先級問題解決情況及業務簽字驗收情況。給出結論，系統是否具備上線條件。
測試階段需注意培訓手冊的編寫。一般由業務用戶輸出，但質量較差，達不到要求。上線後，業務表示看不懂操作手冊，碰到任何問題直接找IT，最後還得由系統管理員逐漸完善操作手冊。因此測試階段，要求由乙方提供通用版操作手冊，業務審覈通過後，在測試階段開始補充，輸出適合本公司業務現狀的、按崗位區分的操作手冊。
測試常碰到的問題，一是測試不夠充分，業務用戶參與意願不強，測試進度慢，測試不深入，僅按照最短路徑原則完成主幹流程的操作。這屬於正常現象，人對於測試有種天生的厭煩感，認爲是不增值的苦差事，而不是覺得是爲了減少上線實際使用的不便，彷彿現在測試的系統不是以後與他的日常工作緊密關聯的工具。針對這個問題，需提前獲得領導的支持（這個不難，都到測試階段了，而且需要的資源不是很多），佈置測試作業，交代要完成的測試任務及時間點。同時顧問與關鍵用戶需現場配合指導；二是發現關鍵問題後就認爲ok了，等待迴歸測試，或二次測試時再做後續測試。需在測試安排中說明清楚，測試截止日期。