Enterprise software testing covers purchased, configurable large-scale systems such as SAP. The focus is less on the local change itself than on how it affects dependent processes and interfaces. The biggest challenge is collaboration: the testers are usually experienced business users without testing training, and configuration changes can cause far-reaching side effects that are hard to predict.
Key Takeaways
- Configuration changes in enterprise systems such as SAP ripple through the whole system, because many parameters depend on each other. Testing only the changed function locally is never enough.
- Business users who test without any testing training check the happy path almost exclusively. Their working life has taught them to work around problems, not to go looking for them.
- Sorting defects into categories (a training gap, missing permissions, a functional error found too late or a genuine integration error) teaches a team more than any abstract retrospective.
- Coverage charts that management understands draw attention and win teams more time for testing, even when the metric behind them is weak.
- Experienced business users are the strongest resource for exploratory testing in enterprise environments. They bring years of system knowledge and have a personal stake in the software working.
What Sets Enterprise Software Testing Apart
Enterprise software testing deals with purchased systems that have been customized for a company and are meant to map its processes. SAP is the best-known example, but the category is bigger than that: specialist systems for social welfare offices or other large organizations work the same way. A preconfigured system, a huge user base, local adaptations.
The key difference isn’t the local change. It’s what the change does. Functionally testing a single customization is usually a side issue, because the developer or configurator covers that well enough. Things get interesting as soon as you look left and right: how does this parameter affect the rest of the system?
Ursula Beiersdorf sums it up with a vivid image: SAP is like one big global variable where a lot is connected to a lot. That effect of a configuration change is what you are really testing. On top of that, much of the complexity sits in the interfaces to and from SAP, in dependencies that a typical agile team simply doesn’t have in this form.
A common misconception is that standard software has already been tested, so a few adjustments can’t hurt. That is often true for the software as a product. But the many ways to intervene and the external dependencies create side effects that surface late in the process. Anyone who treats configuration as harmless underestimates it.
The Real Complexity Is in Collaboration
The biggest problem in enterprise testing is coordination, not technology. “I get the people around the table who need to have a say” describes the core of the daily work better than any test method.
Depending on so many people changes the role. Anyone who wants to secure quality in a large system takes on more governance work than in smaller projects. The job is to set narrow, practical rules that are orchestrated centrally, without carrying out every step centrally.
Who Tests Enterprise Applications, and Why That’s Hard
Enterprise testing rarely has trained testers. The people testing are business experts who know the system as users but know little about testing. They have plenty of other work and test on the side.
These experienced users are strong at experience-based testing. If you have used a system for ten years, you know where its nasty spots are, and you look there first. As long as changes stay small, that holds up. For bigger changes, these users lack the tools of the trade and have to struggle through on their own.
Enabling them starts with a different mindset, not a new method. Business users have learned to walk around the puddle. Testing means jumping in with both feet and being glad you did.
“Thinking, as a matter of principle, about what could break is not the mindset you develop when business has taught you to walk around the puddle.”
(Ursula Beiersdorf)
What works best is starting from a real user story that belongs to the person. They write their test, and then you take it apart together. Two patterns show up almost every time: the acceptance criteria are never detailed enough, and only the happy path gets tested. Only once people have experienced this themselves is it worth introducing test design techniques, usually about three steps later.
Getting Business Users to Test with Tiered Packages
Rather than pushing the full methodology on everyone, it helps to reduce the complexity of how you approach people. A team that supports others can shape its offering like a set of products.
- Small package: for people who just need to test a single user story.
- Larger package: for serious integration testing, including test management and tool usage.
- Optimizing version: pipelines and advanced automation for those who need them.
Many start with the small package and quickly notice that it only gets them so far. More important than any package is meeting people where they are. The persuasion work, the why, is organizational change, and it makes up the biggest part of the job. Methods come afterwards, and where an area is truly critical, you bring in a tester or consultant who knows the craft.
Moving from Excel to a Test Management Tool
Excel dominated the enterprise world for a long time, and a hard cut feels counterintuitive at first. The switch works if you tie it to a transformation that is already underway. When using Jira became mandatory, rolling out Xray could happen in the same move.
Legacy software that will be retired in the next few years can stay on Excel. The new tool is mandatory where it counts. Through that mandatory part, the first users come to appreciate the benefits and then join voluntarily: storing test cases in a structured way, seeing their own progress, having tests run by different people. These test management features make a lot of things easier, and word gets around.
Defect Management: Four Categories Say More than Twenty-Five
Not every defect needs a ticket. Small issues that can be sorted out at the “hey Joe” level with an IT colleague you know may be handled that way. As soon as an error can’t be fixed right away, or it’s unclear who is responsible, it should be written up as a defect.
The real insight comes from the evaluation. A simple split into four categories is enough:
| Category | Meaning |
|---|---|
| Training | tester was not sufficiently trained |
| Preparation | permissions or prerequisites were missing |
| Functional test | could easily have been found earlier |
| Integration | genuine integration error |
These four categories are clear and simple, and that is exactly why they work. In one retrospective, a team realized on its own that missing permissions, for example, had held up and annoyed the tester, and decided to prepare better next time. Annoying a tester who has no time to begin with costs trust, and that trust is hard to win back.
It’s tempting to analyze all this in more detail with AI, but that doesn’t fit as long as the basics are missing. If your testing is roughly at a 2005 level of maturity, take a few intermediate steps before you reach for AI. Many ideas from conferences also target custom development and are hard to transfer to a configuration-driven SAP context.
Steering Integration Testing through Process Modeling
Who is responsible when large standard systems are integrated? Process modeling answers that question best. If a program rethinks its processes instead of just migrating the system, the process parts can be merged cleanly and test runs can be derived from them.
To get there, familiar routines that business experts have always done a certain way first have to be cast into processes. That feels cumbersome at first, but it creates a common thread that brings everyone involved together. The process also gives you a structure for discussing whether to test only the happy path or which variants to cover.
On top of that, there are process tests independent of user stories. End-to-end flows that are already in place get tested again and again, because the actual impact of a change is never entirely certain.
Why User Stories Look Different in Enterprise Testing
In an enterprise environment, a user story often spans more than flipping a configuration switch. The mindset is: I change something to achieve a certain effect, so I test that effect.
A counterexample: when a third gender option was introduced, the switch was set quickly. Whether it could then be used correctly when writing letters may never have been tested. Experienced enterprise people tend to be tuned to exactly this chain of effects. Ideally, this view of the impact already goes into refining the user story and becomes part of the acceptance criteria.
Test Data Management in SAP Projects
In a classic SAP environment, you pull a copy of production and hope it contains no critical data. A newly built system doesn’t have that problem, because there simply is no data yet. That raises awareness and forces people to work together.
Testing contributes at one specific point: marking on the process bubbles where each kind of data enters the picture for the first time. Business partners from one interface, materials from another. This transparency helps everyone talk to the right data provider in good time when data is needed.
It’s important to distinguish between basic configuration data and transaction data. Configuration data is developed as part of the program, transaction data isn’t. For intellectual property, a hard rule often applies as well: no external tester gets to see that data.
Test Automation Needs Success Stories First
Test automation in an enterprise environment works on two levels. Whatever is actually developed, developers automate with their own tools, such as Cypress or unit tests. The process level, which spans several tools, is harder.
A tool like Tosca was introduced to help less technical people here, but it failed in practice. It remains an expert tool you have to learn, and users have no spare time for that. Without early wins, nobody adopted it.
The new approach turns this around: first build a central automation team that produces the success stories. Once there is a foundation and it becomes visible that automation takes work off people’s plates, people in the business units are willing to get involved and learn it. Success before breadth.
Cross-cutting processes that touch several tools need central direction. Writing the first three tests in one tool, the next ones in another and wiring them together through a third tool is not a state worth aiming for.
Metrics That Point the Wrong Way but Still Help
A test coverage figure that counts one test case per story says nothing about that test case’s quality. Whether it’s a good one remains open. As a statement about test coverage, the metric is weak.
It still has value. The red and blue bars on the charts are easy to explain, quick to read and fit for management. You can use them to get attention and to make sure people get more time for testing.
If you know the lever, you pull it on purpose. A metric that points the wrong way from a testing perspective but buys people more testing time is worth it, as long as better test cases come out of it later.
The Next Big Lever: Exploratory Testing
The biggest untapped potential in enterprise testing lies with experienced users and their exploratory testing. They have years of experience with the system and are very receptive when you show them how to sharpen their intuitive approach.
Experience-based techniques fit especially well here, for example heuristics on a compact cheat sheet. Users only need to take a little time to learn them. You’re pushing on an open door.
Automation and exploratory testing complement each other, but they speak to different audiences. As long as automation is still thin, good exploratory testing goes a long way, especially where experienced users are close to the system anyway and have a strong personal interest in it working. After all, they’re the ones who have to live with it later.
Frequently Asked Questions
Is it enough to test only the modified function after a configuration change in a system like SAP?
No. Functional testing of the individual customization is usually secondary, because developers or configurators cover it thoroughly themselves. What matters most is the impact upstream and downstream: SAP behaves like a large global variable in which many elements are interconnected. Added to this are the interfaces to and from SAP. Otherwise, side effects tend to surface late in the process.
How is the role of quality assurance changing in large system landscapes?
It’s shifting toward governance. Day-to-day work primarily involves bringing together the people who need to have a say. Instead of implementing every step centrally, you set narrow, actionable rules and orchestrate them centrally. The biggest problem in enterprise testing is coordination, not the technology.
How do you teach business users without testing training how to test?
The most effective way is through a real user story from that person. They write their own test, and then it’s analyzed together. Two patterns almost always emerge: the acceptance criteria aren’t detailed enough, and only the happy path is tested. It’s only worth diving into design methods after this experience, usually three steps down the line.
Does every error found have to be documented as a defect?
No. Minor errors that can be resolved on the “Hey Joe” level directly with a familiar IT colleague can be handled that way. An error is documented only if it cannot be resolved immediately or if it remains unclear who is responsible. Insights are gained only during the evaluation phase anyway, typically organized into four categories: training, preparation, functional testing, and integration.
How can integration testing between multiple purchased large-scale systems be organized?
Through process modeling. If a development team rethinks the processes rather than simply migrating the system, the process components can be merged, and test runs can be derived from them. To do this, familiar workflows must first be translated into processes, a step that may seem cumbersome but brings all stakeholders together. In addition, end-to-end tests are repeatedly run independently of user stories.
Why do business users often reject test automation tools?
Because a tool like Tosca, despite its claim to empower less technical users, remains an expert tool that requires a learning curve. Users don’t have the time for this, and without a sense of achievement, they won’t use it. A more sustainable approach is a central automation team that first delivers visible results. Success before scale.
Is test coverage that counts only one test case per user story even useful?
Hardly as a technical statement, since it says nothing about the quality of that single test case. It’s still useful, though: The red and blue bars on the charts are easy to explain and suitable for management. This helps draw attention and ensure that teams get more time for testing, which later results in better test cases.
Is exploratory testing worthwhile with users who have no formal testing training?
Yes, that’s where the greatest untapped potential lies in the enterprise environment. Anyone who has used a system for ten years knows where the pain points are. Experience-based techniques, such as heuristics on a compact cheat sheet, sharpen this intuitive approach with minimal learning effort. Users have a strong personal stake because they’ll have to live with the system themselves later on.
