By William Perez, SAP Principal Engineer at Foulk Consulting
In my previous post, I discussed the “Hidden ROI” of SAP testing, the idea that the true value of a testing strategy isn’t just in finding bugs, but in accelerating business velocity.
But there is a darker side to that ROI equation: Waste.
After years of auditing SAP environments and streamlining delivery pipelines, I’ve observed a consistent, startling trend that I call The 60% Rule. In most enterprise environments, roughly 60% of the testing effort is redundant, obsolete, or completely unnecessary.
If you feel like your release cycles are bogged down despite a “comprehensive” test suite, you aren’t just imagining it. You are likely over-testing. Here is why it’s happening and how we can stop the bleeding.
The “Safety Blanket” Trap
Why do we over-test? It usually stems from a place of diligence. In the SAP world, the cost of a production failure is catastrophic. To mitigate that risk, organizations default to “testing everything.”
We build massive regression suites that grow with every project, every service pack, and every transport. Over time, these suites become a “safety blanket.” We run them because we’ve always run them, not because they are actually validated against the changes we are making.
The result? You’re spending 100% of your budget to cover 40% of your actual risk, while the other 60% of your effort is spent testing code that hasn’t changed in five years.
The Math of Redundancy
When I say 60% of testing is redundant, I’m looking at three specific areas:
- The Overlap: Multiple test cases hitting the same transaction paths or business logic.
- The Obsolete: Testing “Z-programs” or custom enhancements that the business hasn’t actually used since 2019.
- The Low-Risk: Expending manual effort on low-impact UI changes that have zero effect on the underlying financial or logistical database integrity.
This isn’t just a technical inefficiency; it’s a massive drain on ROI. Every hour spent on a redundant test is an hour stolen from S/4HANA migration prep, innovation, or feature delivery.
How to Stop: Moving from “Volume” to “Velocity”
To break the 60% Rule, we have to move away from the “test everything” mindset and move toward Change Impact Analysis. Here is the roadmap I use at Foulk Consulting to help our clients pivot:
- Audit Your Transports: Instead of guessing what might break, use tools to analyze exactly which objects are being touched by a transport. If the change is in HR, why are you running a full Sales and Distribution regression?
- Identify Your “Hot Spots”: Use usage data to see what your users actually do. If a specific T-code is used 10,000 times a day, it deserves 90% of your attention. If it’s used once a quarter, it shouldn’t be clogging up your automated suite.
- Prune the Suite Relentlessly: A test suite should be a living organism, not a museum. If a test hasn’t failed in two years and the code it covers hasn’t changed, it’s a candidate for retirement or lower-frequency testing.
The Bottom Line
Stopping the over-testing cycle requires a shift in culture. It requires moving from a “fear-based” testing model to a “data-driven” one.
By eliminating the 60% of redundant effort, you don’t just save money—you gain the agility required to keep up with the modern pace of SAP updates. You stop being the bottleneck and start being the engine.
Is your testing suite a safety blanket or a strategic asset? At Foulk Consulting, we specialize in helping SAP teams find that 60% waste and reinvesting it into true business value. If you’re ready to stop over-testing and start delivering, let’s talk.
