Lesson 1 of 5
Anatomy of a good SAP defect
8 min
Listen to this lesson
A defect report has one job: let someone who was not there understand the problem, reproduce it and fix it. On an SAP program that someone is often a consultant in another time zone, looking at a different client, a day later. Every missing detail costs a round of questions and a day of delay. A good report answers those questions before they are asked.
The minimum fields
The ISTQB Foundation syllabus lists what a defect report typically contains: an identifier, a title and summary, date and author, the test object and environment, the context (test case, activity), a description that allows reproduction, expected and actual results, severity, priority, status and references. SAP programs add landscape details, because the same steps behave differently in different systems and clients.
| Field | Why it matters in SAP | Contoso example |
|---|---|---|
| Title | Searchable one-line summary of the failure | Billing for fleet customers posts revenue to G/L account for other income |
| System, client, baseline | Results depend on landscape and imported transports | S/4HANA QAS, client 100, integration build 7 |
| User and role | Authorizations change behavior | Test user for billing clerk business role |
| App or transaction | Fiori app and SAP GUI paths can differ | Create Billing Documents app (also seen in VF01) |
| Test data and document numbers | Lets others display the exact documents | Customer Great Lakes Fleet Services; order 1000457; delivery 80001234; billing 90001877 |
| Steps to reproduce | Numbered, minimal, from a known starting point | 1. Open delivery 80001234. 2. Create billing. 3. Display journal entry. |
| Expected result, with source | Shows what "right" is and who said so | Revenue to the fleet revenue account per design document FIN-07 |
| Actual result | What happened, with values and messages | Revenue posted to the other-income account; amount $12,500.00 |
| Messages and attachments | Message ID and number identify the exact check that fired | Screenshot of journal entry; message long text if any |
| Links | Traceability to test case and requirement | Test case O2C-FLEET-01; requirement REQ-12 |
Minimum defect fields for an SAP program.
Messages: capture the ID, not just the words
When SAP shows an error or warning, the text alone is often ambiguous. Every SAP message has a message class and number. In SAP GUI, open the message's long text (double-click it in the status bar or use the help) to see them; in Fiori apps, the message popover offers details. The ID tells a consultant exactly which program check produced the message, which is often half the diagnosis. Copy the ID and the long text into the defect.
- See the messageError or warning in the status bar or Fiori message popover
- Open the detailsLong text in SAP GUI, or the details in the Fiori popover
- Note the IDMessage class and number
- Copy into the defectID plus long text, next to the steps that produced it
Before you log, try to reproduce the failure once more from a clean start, ideally with a second set of data. If it happens only with Great Lakes Fleet Services and not with another fleet customer, that difference is a clue worth recording. If it does not happen again at all, log it anyway with everything you captured and mark it as intermittent; some of the most serious SAP problems, such as locking conflicts in high-volume postings, show up only now and then.
- Does the failure happen again from a clean start?Yes → go on · No → log it anyway, marked intermittent, with everything captured
- Does it happen with a second set of data?Yes → log it as a general failure · No → record the data difference as a clue
- Does it happen only for one customer, plant or role?Yes → name that condition in the title, for example only Great Lakes Fleet Services · No → log as reproduced
Weak and strong side by side
| Element | Weak report | Strong report |
|---|---|---|
| Title | Billing broken | Fleet billing posts revenue to other-income account instead of fleet revenue |
| Where | Not stated | QAS client 100, build 7, billing clerk role |
| Data | A customer | Great Lakes Fleet Services; delivery 80001234; billing 90001877 |
| Steps | Did billing, it failed | Three numbered steps from the delivery to the journal entry |
| Expected | Should work | Revenue to fleet revenue account per design FIN-07 |
| Actual | Wrong | Revenue $12,500.00 to other-income account; journal entry attached |
| Links | None | Test case O2C-FLEET-01; requirement REQ-12 |
Keep opinions about the cause out of the description, or label them clearly. "Probably the account key in the pricing procedure" is useful as a separate hypothesis line, but if it is woven into the facts it can send the fixer in the wrong direction. Facts first: what you did, what you expected and why, what happened.
What would you do?
Maria reports in a chat message: "Pricing is wrong for Great Lakes again." Priya needs to turn this into a defect. What should she capture first?
- A defect report must let someone who was not there reproduce and fix the problem.
- SAP reports need system, client, baseline, user role, app, document numbers, steps, expected (with source) and actual.
- Capture message class and number, not only the text.
- One failure per defect; separate facts from hypotheses.
Check your understanding · not graded
Lesson check
1. Which item is most important to include so a developer can reproduce an SAP defect?
2. Why record the message class and number for an SAP error?
3. Billing posts to the wrong account and the invoice form shows the wrong date. How many defects?
4. Why include the source of the expected result?