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