Automated Testing: Key to Effective SAP VC to Tacton CPQ Migration

You can’t test a CPQ model by clicking through it.

That’s one of the biggest misconceptions we see when manufacturers migrate from SAP VC/AVC to Tacton CPQ. Teams often rely on GUI-based testing - step through the configuration, make sure it works. But CPQ models can include thousands of combinations, edge cases, and logic branches. Manual testing only catches what you look for. That’s why automated tests in Tacton CPQ are essential - not optional - for model validation. In this final part of our series, we’ll show how test suites help you find issues early, prevent silent failures, and support long-term model quality.

Here’s a simple example.

Let’s say your CPQ model includes a component: Sleeper Cab A. It’s only available with Chassis XL, which you define through a combination class. Everything looks fine in the GUI - until one day, the chassis options change. Chassis XL is retired and replaced with Chassis Deluxe. Suddenly, Sleeper Cab A becomes impossible to select. No one notices until a customer asks, "Why can’t I buy this option anymore?"

Automated tests would have caught that.

In Tacton CPQ, test suites let you define expected behaviors and validate them continuously. You can build tests that check things like:

• Is every component selectable at least once?
• Are all required feature combinations covered by valid configurations?
• Do key use cases still produce valid solutions after a model update?
• Does pricing still calculate correctly across variants?

At cpq.se, we help clients set up automated test coverage as part of their modelling process. It’s not about catching bugs at the end - it’s about building confidence throughout. Each time you change a rule, import a new variant table, or update a feature, your test suite acts like a safety net.

This is especially useful in converted models from SAP VC/AVC, where the logic may not be fully understood yet. Tests help validate assumptions:

• Did we translate the rule correctly?
• Is the combination class complete?
• Are any constraints failing silently?

Another advantage: you can automate test runs as part of your workflow. Every time the model is updated, run the test suite. If a test fails, fix it before the issue hits production. This approach helps keep model quality high, even as the product evolves.

Testing also improves collaboration. Business consultants and modelers can discuss requirements in terms of test cases. For example: “This configuration should always be valid.” “This option should never be available with that chassis.” These scenarios are easier to align on when they’re written as tests instead of informal notes.

And unlike GUI testing, which is slow and inconsistent, automated tests are fast and repeatable. They scale with your model. As the complexity grows, your test suite grows too - without adding hours to each release.

Here’s how to get started:

• Begin with coverage tests: ensure all options can be selected.
• Add key scenario tests for your most common product configurations.
• Create boundary tests: rare combinations, new options, phased-out parts.
• Automate test execution as part of your development process.
• Treat failures as model quality feedback - not as bugs to patch manually.

Automated testing won’t catch every issue - but it will catch the ones most people overlook. And in CPQ, those silent failures are the ones that cost you time, money, and trust.

That wraps up our six-part series on SAP-to-CPQ conversion. Whether you’re starting from scratch or fine-tuning your Tacton CPQ models, remember: structure matters, constraints aren’t always your friend, and testing is the only way to keep your model healthy over time.

Need help building a test-first modelling process?
Magnus and Patrik from cpq.se can show you how to set up effective test coverage: https://www.cpq.se/meetcpqse

For more on model validation and structure:
https://www.cpq.se/the-cpq-blog/tacton-studio-modeling