Lesson 2 of 6
Diagnosing an SAP failure before you log it
9 min
Listen to this lesson
Not every red message is a defect in the system. The ISTQB Foundation syllabus separates the terms: a person makes an error (a mistake), which produces a defect in a work product such as configuration, code, master data or even a test script, and an executed defect can cause a failure, the behavior you observe. The root cause is the underlying reason, found by root cause analysis. The syllabus also warns that a reported anomaly may turn out to be a false positive or a change request. On an SAP program, ten minutes of diagnosis before you log saves a day of misrouted work.
First, what kind of anomaly is it?
Two of those exits still deserve a record. If the missing data came from a migration load, the load itself has a defect, owned by the data team. If CMQ is not on the planned build, the result belongs to a build nobody meant to test: note the baseline and rerun after the import. And the defect can sit in the test itself. A wrong expected value in test case O2C-FLEET-01 is a defect in the test basis, fixed by the test team rather than the consultant, and it should be counted that way.
Where SAP keeps the evidence
| Symptom | Where to look | What to copy into the defect |
|---|---|---|
| Error or warning message | The message long text: in SAP GUI double-click the message; in Fiori open the message popover | Message class and number, full text, the field it points to |
| A short dump ("runtime error") ends the transaction | ST22 ABAP runtime errors, filtered by user and date | Runtime error name, exception, program, date and time |
| "No authorization" in SAP GUI | SU53 right after the failure, on the same application server | The failed authorization object and its field values |
| A Fiori app won't start or shows no data | Launchpad user menu, About, for the app ID; /IWFND/ERROR_LOG for OData errors; an authorization trace with STAUTHTRACE | App ID, user, time, the error log entry |
| "Saved", but the document doesn't exist and an express message says the update was terminated | SM13 update requests | Update key, function module and error text |
| A background job did nothing or failed | SM37 job overview and job log | Job name, variant, start time, log messages |
| A mass run or posting program reports errors | SLG1 application log, by log object and date | Log object, external ID, the message lines |
| An IDoc was not processed | WE02 IDoc display; BD87 status monitor | IDoc number, message type, status (for example 51, application document not posted) and its messages |
Where to find the evidence for common SAP failure types. In CMQ, testers often need Basis, security or development to open some of these transactions.
Fiori needs one more rule. SU53 keeps failed checks per application server, and a Fiori app's OData calls may run on a different server from your SAP GUI session, so opening SU53 afterward in a separate session can show the wrong check or none. Contoso's security team, led by Nadia, uses an authorization trace with STAUTHTRACE and the gateway error log /IWFND/ERROR_LOG instead. Your job as the tester is to give them the app ID, the user and the time. Where the launchpad's App Support function is enabled (it needs its own authorization), it shows authorization and configuration errors for an app directly.
What would you do?
Ana posts a supplier invoice for Lakeside Components in CMQ. The app shows a document number, but a minute later an express message says the update was terminated, and the document cannot be displayed. What should happen?
- An error produces a defect, which may cause a failure; root cause analysis finds why.
- Rule out preparation gaps, a different build and missing expectations before logging; defects can also sit in test cases and data loads.
- Copy SAP's evidence: message class and number, ST22 dump, SU53 or trace, SM13, SM37, SLG1, IDoc status.
- Record the user and the time to the minute, so logs can be found.
- For Fiori authorization failures, use STAUTHTRACE and /IWFND/ERROR_LOG, not SU53 in a separate session.
Check your understanding · not graded
Lesson check
1. In ISTQB terms, what is the behavior you observe when a defect is executed?
2. A posting showed a document number, but the document does not exist and an update-terminated message arrived. Where is the key evidence?
3. A Fiori app shows no data for Ana and an authorization problem is suspected. Under Contoso's rule, what is used to diagnose it?
4. A test fails only because the test case expects the wrong fleet price. Where is the defect?