Lesson 5 of 5
Limits and judgment
12 min
Listen to this lesson
Object-based impact analysis is powerful and incomplete. It sees what static references and recorded traces show. SAP behavior, however, is heavily driven by configuration data, runtime decisions and other systems. A mature test lead knows exactly where the tools go blind and puts expert judgment there.
What object-based analysis cannot see well
- Dynamic calls. Code that decides at runtime which program, function module, method or table to use (for example a function name held in a variable, or a dynamically built database access) does not show up reliably in where-used lists.
- Configuration-driven behavior. A changed entry in a pricing procedure, a condition table, an account determination table or an output determination changes behavior without changing any code. Traces show the program that reads the table, not which entry matters.
- Enhancements chosen at runtime. BAdI implementations and enhancement filters are selected by context. A trace recorded for one plant may not show the implementation used for another.
- Master data effects. New condition records, changed bank details or a different valuation price change outcomes with no technical change at all.
- Front-end and integration. Fiori and UI5 changes, middleware mappings and partner systems sit outside ABAP traces.
- Authorizations. A role change can stop a process for some users while every object is untouched.
- Timing and volume. Batch job chains, period-end sequences and performance under load are not visible in an object list.
Putting judgment where the tools are blind
Run a short impact review with the functional consultants and process owners for each value stream after the automated or tool-assisted analysis. Give them the change inventory and the draft scoped list, and ask three questions: What changed that is not in a transport? Which configuration entries changed, and which business situations hit them? What happens on the other side of each changed interface? Their answers become additional rows in the scoped list, each with "identified by SME review" as part of the rationale.
- Tool-assisted analysisObjects traced to process steps and filtered by usage
- Draft scoped listInclusions, exclusions and depth with rationale
- SME review per value streamWhat changed outside transports? Which config entries? What happens across interfaces?
- Add rowsNew lines marked "identified by SME review"
- Owners confirmProcess owners approve the final list
| Blind spot | Question for the SME | Contoso example |
|---|---|---|
| Configuration data | Which business situations hit the changed entry? | New account determination entry hits export customers only |
| Runtime enhancements | Which org units or contexts select a different implementation? | Plant 1720 uses a separate BAdI implementation for batch handling |
| Master data | Which data loads or mass changes happen in the window? | Fleet rebate condition records loaded the same weekend |
| Integration | Did the partner system or middleware change too? | Fleet customer moves to a new EDI message version |
| Authorizations | Which roles changed, and which users hold them? | Billing clerk role loses a display authorization |
Questions that surface what tools miss.
- Was the change in the inventory?Yes → next question · No → improve the inventory checklist, such as asking for data and interface changes
- Did the analysis reach the affected process?Yes → next question · No → fix object-to-process mappings or add an SME review question
- Was the process scoped out?Yes → review the rationale against the evidence available · No → it was tested: improve test design and depth
The baseline as a safety net
Because no analysis is complete, keep the baseline regression from lesson 4 running every release, and keep it automated where possible. It catches the unexpected breakage in a critical flow that every analysis method missed. Think of impact analysis as deciding what to test in addition to the baseline, not instead of it.
What would you do?
Contoso's tool-assisted analysis of R2 finds no impact on billing. During the SME review, Dan mentions that a customizing transport changed the revenue account determination for one account assignment group, used only for export customers. What should Priya conclude?
Being honest about limits at sign-off
Present impact analysis at sign-off for what it is: an evidence-based selection, not a guarantee. A short statement in the test summary helps: which analysis methods were used, which areas were reviewed by SMEs, which exclusions were made and on what evidence, and that the baseline regression ran in full. Decision makers can then judge the residual risk of what was not tested, rather than assuming everything was. This is also the best protection for the test team. When a scope decision is challenged later, a documented method applied consistently is far easier to defend than an undocumented guess that happened to go wrong.
Finally, resist the pressure to let tools make the final call alone. Tool output is a strong starting point for scope. The final list is a judgment shared by the test lead and the process owners, informed by tools, release information, usage and risk.
- Object-based analysis misses dynamic calls, configuration data, runtime enhancements, master data, front-end, integration, authorizations and timing.
- Put expert judgment on low-visibility, high-impact areas.
- Run an SME impact review for each value stream and record what it adds.
- Keep the baseline regression as a safety net; learn from every escaped defect.
Check your understanding · not graded
Lesson check
1. Why can a dynamic function call escape a where-used list?
2. Which change is MOST likely to be missed by object-based impact tools?
3. What is the purpose of an SME impact review?
4. How should the baseline regression relate to impact analysis?