In this article, Zooss Technical Director Gerry Ramdeen explains why testing in a planning implementation is a discipline to be designed from the start – not a phase to be squeezed in at the end – and what separates the teams who go live with confidence from those who don’t.
Ask a project manager when testing starts, and most will point you to the test phase on the Gantt chart. It’s usually near the end. It usually has the least buffer. And it’s almost always the first thing that gets compressed when earlier phases run long.
This is one of the most predictable failure patterns in planning implementations. Not because project managers are careless, but because testing is still widely treated as a validation exercise that happens after the model is built, rather than a discipline that needs to be designed in parallel with everything else.
In practice, the teams who go live with the highest confidence are the ones who started thinking about testing the moment they started thinking about data.
Testing phases in a planning implementation
Enterprise planning implementations typically move through several layers of testing before go-live. Unit testing confirms that individual components behave as designed. Performance testing stress-tests the model under realistic data volumes. Regression testing checks that fixing one thing hasn’t broken another. Each has its place.
But in this article, we are focusing on the two phases that carry the most weight in a planning implementation, and the two that are most commonly mismanaged, System Integration Testing (SIT) and User Acceptance Testing (UAT). Not because the others don’t matter, but because these are the phases that directly determine whether the solution is technically sound and whether the business will actually trust it.
The teams who go live with the highest confidence are the ones who started thinking about testing the moment they started thinking about data.
Gerry Ramdeen, Technical Director
SIT comes first. It is a technical exercise, performed by the implementation team, that validates whether all the moving parts of the solution communicate correctly. APIs, data pipelines, batch jobs, load processes, error handling: the full integration landscape is exercised to confirm that data flows accurately from source systems into Anaplan and back out again. The focus is on identifying defects before business users ever touch the model.
UAT follows. It is a business exercise, performed by real end users with production-quality data, that validates whether the solution meets business requirements and is operationally ready. The question SIT answers is “does it work?” The question UAT answers is “does it work for us, in our context, in the way we actually need it to?”
The distinction matters enormously. SIT without UAT gives you technical confidence but not business confidence. UAT without proper SIT means your business users discovers integration defects that should have been caught weeks earlier. Both phases are necessary, and neither can substitute for the other.
Why testing starts long before the test phase
Here is the uncomfortable truth about planning model testing: the quality of your tests is only ever as good as the quality of your test data.
This is why the conversation about testing needs to start in the data foundations and requirements phase, not because you need to write test scripts at that point, but because the decisions made about data during discovery directly determine what you can and cannot test later.
Consider what SIT actually validates. It checks that data flows between integrated systems and lands in Anaplan with integrity intact. It verifies that product hierarchies from the ERP translate correctly into planning hierarchies. It confirms that actuals load to the right cost centres, that exchange rate logic applies correctly, that prior-year comparatives reconcile to the expected totals. Every one of these tests depends on having data that is clean, representative, and mapped correctly to planning dimensions.
If those mappings haven’t been resolved, if the product hierarchy decisions from Part 3 of this series are still open, if master data governance hasn’t been established, if the reconciliation framework hasn’t been designed, then SIT cannot be completed. You end up running integration tests against unresolved data structures, which produces noise rather than check points. You cannot tell the difference between a genuine defect and an artefact of incomplete source data. SIT incorporates data quality checks, not just systems are running with no errors.
The same logic applies to UAT, with even higher stakes. The Anaplan UAT framework requires test data that is production-quality, sanitised from real business transactions, covering standard scenarios, edge cases, exceptions, and negative scenarios, and structured to reflect the actual roles and access profiles of your users. Creating that dataset is not a two-day exercise before UAT begins. It is a sustained effort that runs alongside model build, drawing directly on the data integration work that was happening in parallel and the calculations within model development.
When test data is genuinely representative, UAT produces meaningful results. Business users exercise the model in conditions that approximate real-world use. Defects surface because the scenario was realistic, not because the data was artificial. Sign-off has substance because the testing had substance.
When test data is a rushed approximation, UAT becomes theatre. Users go through the motions. Issues emerge after go-live because the test never encountered the actual volume, the actual edge cases, or the actual data quality your production environment produces every day.
Two gates, not one
The structured use of entry and exit criteria is one of the most valuable, and most underused, elements of the Anaplan testing framework.
Entry criteria define what must be true before a testing phase can begin. For SIT, this means unit testing is complete, integrations are configured, and a stable testing environment is available. For UAT, the bar is higher: SIT must be completed and signed off, the UAT environment must be stable and production-like, test cases must be approved by business stakeholders, and production-quality test data must be available and validated. These are not suggestions. They are gates.
Exit criteria define what must be true before a testing phase can be considered complete. For UAT, this means all planned test cases have been executed, no critical or high-severity business defects remain open, medium and low defects have been documented and formally accepted, and business sign-off has been obtained. Deployment cannot proceed until these conditions are met.
This gate structure serves a purpose beyond process compliance. It forces an honest conversation about readiness. Without formal exit criteria, there is constant pressure to declare testing “good enough” in order to hit a go-live date. With them, the conversation shifts, these are the standards the business agreed to upfront, and the data either meets them or it doesn’t.
What goes wrong when testing is an afterthought
The failure pattern is consistent across implementations where testing has been treated as a phase rather than a discipline.
Testing begins with inadequate data. The team loads a sample extract from the source system that was never validated against planning hierarchies. Critical product codes are missing. Customer hierarchies don’t reconcile. The first SIT cycle produces a long list of issues that turn out to be data issues rather than model defects. Time is lost triaging noise.
UAT is scheduled for the week after SIT completes. Business users are booked. Then SIT runs long. The UAT window compresses. Users get two days instead of two weeks. They test the happy path. Nobody runs the month-end close scenario, the exception override scenario, or the scenario where an actuals load fails midway and needs to be retried.
The model goes live. In the first real planning cycle, Finance discovers that the variance commentary workflow breaks when a cost centre has no prior-year actuals. Supply chain discovers that the exception flag logic doesn’t account for negative inventory balances. These are not edge cases, they are normal business conditions. They just weren’t in the test data.
Executive leadership, who signed off on go-live, is now being told that the system has issues. The platform’s credibility takes a hit before it has delivered a single planning cycle.
Testing as the foundation of confidence
There is a dimension to UAT that goes beyond defect detection, and it is arguably the most important one: Business confidence.
Early access can help here. Giving business users hands-on time with the model before UAT begins even with a partially built solution (but with good data) allows them to build familiarity, surface questions and develop a sense of ownership before the stakes are high. By the time formal UAT begins, they are reviewing rather than discovering.
Business users who have tested a system, who have sat with it, challenged it with their real scenarios, and watched it handle complexity correctly, develop a fundamentally different relationship with it than users who were simply trained. They have evidence. They have seen what the model does with their data, in their roles, across their processes. When they sign off on UAT, that signature represents informed conviction, not administrative compliance.
The testing phase does not stand alone. It is the point at which every upstream decision is validated simultaneously.
- The data foundations discussed in Part 3 of this series, were they solid? SIT will tell you.
- The model design from Part 4, does it perform under real data volumes? SIT will tell you.
- The requirements gathered in Part 2, were they accurately translated into working functionality? UAT will tell you.
- The business case from Part 1, can the organisation actually use this platform with confidence? UAT sign-off will tell you.
Testing is not the end of the project. It is the proof of the project. Every phase before it was building towards this point, the moment when a real business user, with real data, exercises the model against real business processes and confirms that it is ready.
That proof is only possible if testing was designed as part of the plan from the beginning. If the data foundation was built with testing in mind. If the model was designed with testability as a criterion. If the business was engaged in defining what acceptance actually means, before anyone wrote a single test script.
Start planning the test before you start building the model. That is how you make go-live a non-event.
Find out more
- Sustainable Business Planning – Our solutions
- Anaplan Partner delivering better planning for businesses in Australia & NZ
- Worldwide reach, local expertise: Global Anaplan Implementation Network
- Ready to transform your planning? Contact us.
Better Planning. Better Planet.