Lesson 5 of 5
Testing outputs
9 min
Output defects are embarrassing because they are public, and they are easy to miss because SAP reports "completed" when an email was handed to the mail server, not when the right person read the right invoice. Output testing therefore has to look at the output itself and at where it went.
What to test
| Area | Test | Contoso example |
|---|---|---|
| Content | Every field on the form matches the document: partners, addresses, items, prices, tax, totals, payment terms, texts | Invoice 90001877 shows $11,500 net, tax and the 5% discount line |
| Recipient | The right partner and contact, with the right email address, Cc and Bcc | Great Lakes Fleet Services accounts payable mailbox; Cc account manager |
| Channel | Email where expected, print where expected, EDI for EDI partners | Email for fleet customers; print for one-time customers |
| Trigger | Output created at the right event, once; repeat output when requested; no output on irrelevant changes | Invoice sent on posting; not again when a text is changed |
| Language and layout | Each language in scope; long texts, many items and page breaks | An invoice with 40 items spanning three pages |
| Errors | Missing email address or printer produces an error item that someone sees and fixes | Customer with no email address on file |
Output test areas.
Evidence: previews and logs
Two pieces of evidence matter. The output preview (the rendered PDF) proves content and layout; save it with the test. The output log, meaning the output item's status and history on the document, proves the determination result and dispatch: which output type, recipient, channel and form were used, when, and whether processing completed or failed. For email, add the received message in the test mailbox; for print, a photo or scan of the printed page from the test printer; for EDI, the IDoc or message status.
- Expected resultOutput type, recipient address, channel, form, language and key field values written down
- TriggerCreate or change the business document in client 100
- Output itemCheck status and determined parameters on the document
- PreviewSave the PDF and compare each key field with the document
- ReceiptConfirm arrival in the test mailbox, test printer or EDI monitor
- Repeat and negativeChange the document and confirm no unwanted output; test a missing-address error
Build expected results before you trigger anything. For each scenario write down the output type, the recipient address, the channel, the form and language, and three to five key values that must appear on the document, such as the invoice total and payment terms. A tester who only looks at the PDF and says "looks fine" will miss a wrong address in the footer or a missing tax line. A short checklist per output type makes the review fast and repeatable for Maria's key users.
Regression
Outputs depend on many other things: pricing (values on the form), business partner data (addresses and emails), texts, tax and the forms themselves. After any change in those areas, re-preview a small set of reference outputs and compare them with the saved previews from the last release. Differences are easy to spot side by side and much cheaper to fix before a customer calls.
What would you do?
Priya's output test for invoices says: "output status completed – PASS." Dan asks whether that proves the customer received a correct invoice. What is the best answer?
- Test content, recipient, channel, trigger, language and error handling.
- Evidence: saved output preview compared field by field, plus the output item status and history.
- Add proof of receipt: test mailbox, test printer or EDI monitor.
- Re-preview reference outputs after changes to pricing, partner data, texts, tax or forms.
Check your understanding · not graded
Lesson check
1. What does an output status of "completed" prove?
2. Which evidence proves an invoice output's content?
3. Why test changing a billed document after output?
4. Which negative test belongs in an output pack?