SAP ABAP Real Project Debugging Interview Questions: Breakpoints, ST05, SAT and Scenarios

SAP ABAP INTERVIEW PREPARATION SERIES • PART 14

Real project debugging interviews test how you think under pressure. This guide covers a repeatable investigation workflow, debugger techniques, breakpoints and watchpoints, background jobs, update tasks, RFC/OData calls, authorization failures, ST05 SQL trace, SAT runtime analysis, production-safe evidence, and scenario-based answers.

Learning outcome: Diagnose functional and performance defects systematically, select the right SAP tool, explain evidence clearly, and propose a low-risk fix with verification.

1. The interview-ready debugging workflow

1. State the symptom: who, what, where, when and expected result.
2. Reproduce safely: use the same input, user, client, timing and execution channel.
3. Narrow the scope: UI, authorization, application logic, update task, integration, database or infrastructure.
4. Choose the tool: debugger, logs, ST05, SAT, dump analysis or application trace.
5. Collect evidence: call stack, variable change, SQL statement, runtime hotspot or message.
6. Fix the cause: make the smallest justified change and add a regression test.
7. Verify: compare before/after behaviour, performance and side effects.

2. Breakpoints and watchpoints

A breakpoint stops at a source position. A watchpoint stops when a selected variable or expression changes. Use a breakpoint when you know the execution location; use a watchpoint when you know the wrong value but not where it is changed.

• Session breakpoint: useful in the current user session.
• External breakpoint: useful when execution starts through HTTP, RFC, OData or another user context, subject to system rules.
• Conditional breakpoint: avoids stopping on every loop iteration.
• Watchpoint: isolates the statement that changes a business-critical field.

"Illustrative debugging target
LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<item>).
  IF <item>-quantity < 0.
    <item>-status = 'E'.
  ENDIF.
  lv_total = lv_total + <item>-amount.
ENDLOOP.

"Set a conditional breakpoint for a specific item,
"or a watchpoint on lv_total to find the unexpected change.

3. Read the call stack before changing code

The call stack explains how execution reached the current statement. Check the caller, event, enhancement, framework layer and user exit before blaming the visible method. Inspect parameters and global state at the boundary where the value first becomes wrong.

4. Debugging by execution channel

Channel	Practical approach
Dialog	Session breakpoint, call stack and field comparison
Update task	Enable update debugging, inspect update records and confirm commit boundaries
Background job	Reproduce with job user/variant; inspect job log, spool, dump and authorization
RFC/OData/HTTP	Use an external breakpoint for the executing user and verify destination/request payload
Performance	Use ST05 for database evidence and SAT for ABAP runtime/call hierarchy

5. ST05 vs SAT

ST05 SQL Trace answers database questions: which SQL statements ran, how often, with what duration and access pattern. SAT answers ABAP runtime questions: which procedures, statements and calls consumed time. Start from the symptom. A slow transaction may require both tools, but do not trace more users or time than necessary.

Strong interview answer

“I reproduce the exact slow step, run a narrow trace, sort by total cost and executions, then inspect the access path and source context. I change the data access only after verifying selectivity, indexes, result size and business semantics. I repeat the same measurement after the fix.”

6. Seven real project scenarios

Scenario 1: Total is wrong only for one customer

Compare the failing and working inputs, set a watchpoint on the total or status field, and inspect custom exits or customer-specific configuration. Verify currency, units, duplicate rows and initialization. Do not hard-code the customer as a fix.

Scenario 2: Save succeeds, but data is missing

Check update tasks, commit handling, returned messages, locks and update failures. A debugger stopping before COMMIT does not prove persistence. Confirm database state after the logical unit of work finishes.

Scenario 3: Program works online but fails in a background job

Compare user authorizations, variant values, locale, file access, time zone and available frontend services. Read the job log, spool and dump. Reproduce under the batch user when permitted.

Scenario 4: OData request never reaches your method

Validate service registration, routing, authorization and request metadata first. Use an external breakpoint for the executing user. If the breakpoint is not reached, inspect Gateway error logs before changing ABAP code.

Scenario 5: Intermittent lock error

Capture lock object, key, owner and duration. Inspect enqueue/dequeue symmetry and exception paths. Do not remove locking to make the error disappear; correct the transaction boundary.

Scenario 6: Report becomes slow after data growth

Use ST05 to find repeated or expensive SQL, then SAT if ABAP processing remains dominant. Look for SELECT in LOOP, broad result sets, unnecessary columns, nested table scans and missing key access. Measure before and after.

Scenario 7: Production defect cannot be reproduced

Collect non-sensitive evidence: timestamp, user, transaction, document key, message, correlation ID and execution channel. Compare configuration and code level. Add targeted logging or a test seam through change control instead of guessing.

7. Debugger habits interviewers value

• Inspect the first incorrect value, not only the final error message.
• Use conditional stops to avoid thousands of loop interruptions.
• Check data references, assigned field symbols and table keys.
• Compare old and new values before stepping over updates.
• Read exception objects and return messages completely.
• Respect production access, privacy and performance policies.

8. Common mistakes

• Changing code before reproducing the defect.
• Debugging under a different user or variant.
• Assuming a slow screen always means slow SQL.
• Running broad traces for too long.
• Ignoring update tasks, locks and commit boundaries.
• Using debug changes as a permanent fix.
• Skipping regression and negative-path tests.

9. Interview questions with concise answers

Q: Breakpoint vs watchpoint?
A breakpoint stops at a source location; a watchpoint stops when a selected value changes.

Q: Why might an external breakpoint not trigger?
Wrong executing user, expired/inactive breakpoint, different server/channel, authorization or the request never reaches ABAP.

Q: ST05 vs SAT?
ST05 focuses on database trace evidence; SAT focuses on ABAP runtime and call hierarchy.

Q: How do you debug an update task?
Use update debugging where permitted, inspect update records and messages, and verify commit/rollback behaviour.

Q: How do you prove a performance fix?
Repeat the same workload and compare trace/runtime evidence, result correctness and resource use.

10. Hands-on exercise

1. Create a program where a total is changed in three methods; find the incorrect assignment using a watchpoint.
2. Introduce a SELECT inside a loop, record trace evidence, refactor to set-oriented access and compare.
3. Write a troubleshooting note with symptom, reproduction, root cause, fix and verification.
4. Add an ABAP Unit regression test for the failing input and one negative case.

11. Rapid revision checklist

• Reproduce with the same context.
• Read the call stack and execution channel.
• Use breakpoints for location; watchpoints for value changes.
• Use ST05 for SQL and SAT for ABAP runtime.
• Inspect updates, locks, authorizations and commits.
• Fix the root cause and prove it with repeatable evidence.

12. Official SAP references

• SAP Help: Watchpoints in the ABAP Debugger
• SAP Help: Breakpoints
• SAP Help: SQL Trace
• SAP Help: SQL Statement Analysis

← Part 13   |   Series Index   |   Part 15 →

Interview tip: Do not answer with only transaction names. Explain your hypothesis, evidence, risk control and verification.