CPQ systems are among the most difficult enterprise applications to test thoroughly, and most implementations don’t test them thoroughly. The result is go-lives that uncover pricing errors, approval routing failures, and edge case behaviors that should have been caught in UAT — and often don’t get caught until they affect a real deal.
Building a test strategy that’s adequate for CPQ complexity requires a different approach than testing a simpler application. Here’s how to think about it.
Why CPQ Testing Is Different
A standard enterprise application has a finite set of user flows that can be enumerated and tested. CPQ has a combinatorial problem: the number of distinct quote configurations possible from your product catalog, pricing rules, discount authority matrix, and approval paths is often in the thousands, sometimes more. You can’t test every combination. The test strategy has to be smart about which combinations matter.
The failure modes in CPQ are also different. A broken user interface is obvious. A pricing calculation that returns a slightly incorrect margin for a specific product bundle in a specific discount tier is not obvious — it looks like a number, the quote goes out, and the error surfaces months later in a revenue recognition discrepancy or a margin report that doesn’t add up.
Build the test strategy around your actual risk surface. The highest-risk areas in any CPQ implementation are: products with complex bundle logic, pricing rules that interact with each other, approval thresholds at the exact boundary values, and integrations with external systems. Start there, cover those exhaustively, and expand to lower-risk areas as time allows.
Test Case Design
Test cases for CPQ should be derived from business scenarios, not from the system configuration. The question isn’t “does this pricing rule produce a result” — it’s “does this quote configuration for this type of deal produce the right result for this customer.”
Build your test scenario library from your actual deal history. Pull your last two years of closed deals. Identify the twenty or thirty most common deal patterns — by product mix, by deal size, by pricing complexity, by approval path. Build a test case for each pattern that can be run against the new system and verified against the expected output. These scenarios are the core of your test suite because they represent what actually happens in your business.
Supplement the common patterns with edge cases: deals at the exact discount threshold that triggers a higher-level approval, bundles with the maximum number of options selected, quotes in currencies with unusual conversion timing, multi-entity deals that cross regional approval boundaries. Edge cases are where CPQ bugs hide.
Document expected outputs explicitly before you test. For each test scenario, define what the correct output looks like: specific price, specific margin %, specific approval routing, specific contract clause selection. Testers who know what “correct” looks like find bugs. Testers who are looking for “something that seems wrong” miss the subtle ones.
UAT Ownership and Setup
User acceptance testing for CPQ has to be owned by the people who use the system — sales reps and deal desk reviewers — not just the implementation team. Implementation teams know what the system is supposed to do. Sales reps know what it needs to do to be useful in an actual deal. Those are different things, and the gap between them is where usability problems live that testing by the implementation team won’t catch.
Structure UAT around realistic scenarios, not test scripts. Give reps actual customer accounts, actual products, and actual deal parameters. Ask them to build the quote they would build for that deal. Watch where they get confused, where they make mistakes, and where the system produces a result that surprises them. The surprises are what you’re looking for.
Supplement scenario-based UAT with structured test script execution for the highest-risk cases — boundary conditions, integration points, approval routing at threshold values. Scenario-based testing finds usability and logic problems. Structured test execution finds precision errors in pricing and routing logic.
Performance Testing
CPQ performance testing is often skipped because it seems like an edge case. It isn’t. A quote that takes thirty seconds to load because of a complex pricing calculation is an adoption problem. Reps avoid complex product configurations because they’re slow. Managers abandon approval queues because they time out. Performance issues discovered in production are expensive to fix because they often require architectural changes, not configuration adjustments.
Test performance under realistic load conditions. Generate a large number of quotes simultaneously — whatever represents peak load in your business — and measure system response times. Pay particular attention to the operations that involve complex calculations: multi-product bundles, tiered pricing calculations, approval routing logic that evaluates multiple criteria simultaneously. If response times degrade significantly under load, investigate before go-live.
Regression Testing After Changes
Go-live isn’t the end of the testing problem. Every time pricing changes, every time a product is added or modified, every time an approval threshold is adjusted, there’s a regression risk — the change may have unintended effects on quote scenarios that weren’t directly affected.
Maintain a regression test suite that can be run quickly. A library of twenty to thirty key scenarios that can be run in an afternoon gives you the ability to validate system integrity after changes without a full UAT cycle. The library should cover the highest-volume deal types and the highest-risk scenarios. When a change goes in, run the regression suite. Anything that produces a different result than the baseline gets investigated before the change goes live.
The implementation team can build the regression test framework, but someone on your team has to own its maintenance. Testing discipline in CPQ is ongoing, not a one-time project phase. The organizations that avoid production pricing errors are the ones that built that discipline in during implementation and kept it after go-live.
I work on Revenue Cloud and Q2C implementations at Slalom. If you’re building a testing strategy for your CPQ implementation, connect with me on LinkedIn.