The «UAT base» in the context of the IFS implementation methodology refers to the formal foundation and criteria used for User Acceptance Testing (UAT) before the solution goes live. In IFS projects, UAT is structured within the broader implementation phases, particularly during the Establish Solution and Implement Solution phases. The UAT base involves the following key elements:
- Definition: The UAT base is the set of solution scenarios, business processes, test scripts, data sets, and security profiles that have been confirmed and documented as meeting the customer’s requirements during earlier project stages. It acts as the agreed reference against which the customer validates that the delivered solution fulfills the intended business needs.
UAT Basics in IFS Implementation
- The UAT base includes:
- Verified end-to-end business scenarios and processes.
- Test scripts and acceptance criteria were established and approved in the Solution Acceptance Test (SAT).
- Real or representative migrated data as used in the SAT environment.
- Defined user roles and security settings as they will exist in production.
- UAT is executed by expert users or core users, using SAT test scripts, in a dedicated environment that mimics the final production set-up.
IFS Methodology Context
- The UAT base is established as part of the SAT at the end of the Establish Solution phase.
- The results of UAT (Operational Readiness Test in IFS terminology) are used to validate business readiness and provide final approval before go-live.
- Any deviations, test failures, or required fixes during UAT are fed back for resolution prior to system deployment.
Key Deliverables and Purpose
- Confirm that the implemented solution aligns with the agreed-upon business requirements.
- Validate that integrations, customizations, roles, data migration, and process workflows behave as expected.
- Ensure end users are trained and ready to operate the solution confidently post go-live.
The UAT base represents the official starting point for customer validation activities, ensuring a controlled and traceable acceptance process as required by IFS implementation standards.
Is UAT in IFS Cloud one test or two?
In an IFS Cloud project «UAT» is a generic label that maps onto two formal tests with different owners. The Solution Acceptance Test (SAT) closes the Establish Solution phase: the customer’s core team runs end-to-end business flows on production-like data and accepts the configured solution. The Operational Readiness Test (ORT) sits in the Implement Solution phase: trained expert users run the same scripts while the core team only advises. SAT proves the solution. ORT proves the people.
Decide which one you mean before the word «UAT» goes into a plan, a contract or a sign-off form. A ready structure for both is the SAT and ORT test script and sign-off template (IDK-18) on www.ifs-erp.com.
What must be true before the UAT window opens?
- Scope is frozen. The scenario list is agreed and every scenario has a named business owner. Late additions go through change control, not into the test window.
- Test scripts are written from business processes, not from screens. Each script has a start state, steps, expected result and an acceptance criterion a business user can judge without a consultant.
- Data is representative. Migrated data is loaded and reconciled before testing starts, because failures caused by bad data are hard to separate from real defects. Read the data migration silent killers first and plan the load with the DMM step-by-step guide.
- Roles match production. Testers log in with the permission sets they will have after go-live. Testing as an administrator hides exactly the access problems UAT exists to find. See permission sets and segregation of duties.
- The environment is stable. No configuration changes during the window other than controlled fixes, each recorded.
- Testers are released from daily work, and the thresholds for all of the above are agreed in the test strategy, for example using the Test Strategy template (IDK-17).
How should a UAT window be run day to day?
Run a short daily defect triage for the whole test window. Every defect gets five answers: the cause, whether it blocks the process, whether it is contractual (a deviation from agreed scope) or a new request, the owner, and a closure date. Without those five fields a defect list becomes a negotiation instead of a work plan.
Keep a single tracker as the record of what was tested, by whom, on which data and with what result. A ready structure is described in the IFS UAT test tracker template. For the wider testing picture, including CRIM validation, the acceptance test tool and cutover rehearsals, see IFS Testing: CRIM Validation, ATT and Cutover Rehearsals. For what to automate between rounds, see the IFS Cloud test automation strategy.
What does a clean UAT exit look like?
- Every scenario in the UAT base has a recorded result and a named approver.
- No open defect blocks a business process. Non-blocking items are listed with an owner and a date, usually for the first weeks after go-live.
- Deviations are accepted in writing by the business, not only by the project team.
- Users are trained on the processes they tested. See the Training Plan template (IDK-19).
- The result feeds the go-live decision. The Go-Live Readiness Decision template (IDK-21) and the Cutover Plan template (IDK-20) show how to record it.
Where does UAT usually go wrong?
- SAT and ORT merged into one event. The core team signs off a solution that the real users have never touched.
- Consultants run the scripts. The test then proves that consultants can operate the system, not that the business can.
- Testing on thin data. A process that works on ten orders can fail on the volume and variety of real ones. See go-live is a load test.
- Defects argued instead of triaged. Without the daily triage, scope disputes surface at sign-off.
- Sign-off under date pressure. If the window keeps shrinking, check the wider signals in Is your IFS Cloud project off track?
What happens after UAT?
Accepted scenarios move into cutover rehearsal and go-live. The first weeks after go-live are covered in IFS Cloud Hypercare, and the full sequence of phases, roles and checklists is in the IFS Cloud ERP implementation guide. For ready-made project documents, browse the IFS Cloud Implementation Documentation Kit and read Go-Live preparation and testing on www.ifs-erp.com.
UAT in IFS Cloud: frequently asked questions
What does UAT stand for in IFS Cloud?
User Acceptance Testing: the customer’s validation that the delivered solution supports its business processes. In IFS terminology it corresponds to the Solution Acceptance Test and the Operational Readiness Test.
Who runs UAT in an IFS Cloud project?
The customer. The core team runs SAT, trained expert users run ORT, and consultants advise and fix defects but do not run the scripts.
What is the UAT base?
The agreed set of scenarios, test scripts, data and security profiles that the customer validates against before go-live. It is fixed at the end of the Establish Solution phase.
What must be approved before go-live?
Recorded results for every scenario in the UAT base, written acceptance of any deviations, no blocking defects, trained users, and a go-live decision based on those results.
Need a second pair of eyes on your acceptance plan? Book a 30-minute call.