Verification, not replay

A replayed recording proves only that the clicks happened. A test must prove that the business outcome is right: the order exists, with the right price, the delivery reduced stock, the invoice posted to the right accounts. This lesson turns a GUI script into a test by adding verification at three levels: the immediate message, the created document and its follow-on data.

Three levels of verification

1. Step outcomeStatus bar message type and ID after each critical step; no unexpected popups

2. Document contentRead the created document back: customer, items, quantities, prices, status

3. Follow-on effectsDocument flow, stock change, accounting document, output, interfaces

Verification grows from "the step did not fail" to "the business result is correct".

The Sign-Off Table · thesignofftable.com/academy/sap-tau-201

Level one is necessary but weak: a success message says the system accepted the input, not that the result is right. Level two reads the document back, for example by opening it in display mode or querying it through an API, and compares fields to expected values from the test case. Level three follows the process: after billing, check that the accounting document exists and posted to the expected revenue account; after goods issue, check that stock at plant 1710, storage location 171A, went down by the delivered quantity.

Capturing document numbers

The document number is the link between steps. Read it from the success message's variables rather than parsing the visible text, which changes with the logon language. Store it in the test's run context, use it for every later step and write it to the test log. A test log that says "order 0000012345 created, delivered with 80012345, billed with 90012345" is evidence a reviewer can check in the system.

Create orderVA01; read the order number from the success message variables
Verify orderDisplay it; check customer Great Lakes Fleet Services, CMC-ALT-100, quantity 10, expected net price
DeliverCreate the outbound delivery and read its number; at Contoso, picking and goods issue for 171A run in embedded EWM (warehouse 1710), so the test waits for the goods issue status
Verify stockCheck that stock at 1710 / 171A fell by 10
BillCreate the invoice; read the billing number
Verify accountingCheck the accounting document exists in company code 1710 with the expected amounts

An order-to-cash GUI test with verification after each step.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-201

Where SAP's own tools fit

eCATT builds these ideas into its commands. During SAPGUI recording you can insert GETGUI commands to read values from the screen and CHEGUI commands to check them. Its MESSAGE ... ENDMESSAGE block collects messages raised by the commands inside it and applies rules, checked from top to bottom, that decide whether each message is allowed, expected or a failure, identified by message type, class and number. Whatever framework you use, the same design applies: explicit expected messages, read-back of values, and a clear verdict.

In an eCATT MESSAGE block, the first matching rule decides; unmatched errors fail and expected messages that never arrive fail too.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-201

Weak check	Strong check
No error popup appeared	Success message of the expected class and number, with a document number
The window title changed	The document can be displayed and its fields match expected values
The script waited 10 seconds	The script polled until a status was reached, with a timeout
A screenshot was taken at the end	Document numbers and checked values are logged; screenshots only at key checkpoints
The script ran without stopping	Negative tests confirm that wrong input is rejected with the expected error

Replacing replay checks with verification.

Negative tests and evidence

Verification includes proving that the system rejects what it should. A negative test enters an order for a blocked customer or a purchase order above the $25,000 approval threshold and checks for the expected error or workflow status. These tests are often the most valuable automated checks, because a broken validation causes damage silently. Keep the evidence focused: document numbers, compared values, message IDs and a few screenshots at decisive points. That is what Priya attaches to the test run in SAP Cloud ALM for the regression sign-off.

A negative test passes when the system rejects or holds what it should, and that verdict becomes evidence in SAP Cloud ALM.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-201

What would you do?

A colleague proposes making the billing test "more reliable" by removing the accounting check, because it sometimes fails when the accounting document is not there yet. What is the best response?

Hands-on lab · ACCELQ

Verify the SAP GUI document, not the replay (for learners with SAP GUI access)

In ACCELQ, a value captured in one step can flow to the next as an output parameter. Use that to carry the document number from the save message into a read-back check, and add a negative test.

Practice on Your company's SAP test system in SAP GUI for Windows, with scripting enabled by Basis. For learners with SAP GUI access only; never production.

If you haven't set up ACCELQ yet, do the setup lab first. Then do the labs in lessons 2 and 3 of this course.
Pick a create transaction your team uses for test data in the test system, with agreed test values. Build an Action Create test document from saved elements, ending with Save.
After Save, read the status bar. Find the status bar commands in the command reference, store the document number in an output parameter, and verify that the message type is S, not just that a message appeared.
Make the expected message type an Action input parameter, so the same Action can expect S or E.
Build a second Action Check document that takes the document number as an input, opens the display transaction and verifies customer, material and quantity against expected values.
Chain both in a Scenario. Click the check step's document number and use Parameter Linking to pick the create step's output parameter, not a Test Case value.
Build a second Scenario with only the create step and a Test Case for a blocked test customer your team keeps for this. It expects an E message and no document. Click Save Changes on the Test Cases tab.
Run both Scenarios and open the Test Reports.

Done when The positive run shows the document number passing between steps and the values compared; the negative run passes because the expected error appeared. Keep both reports, noting the system and client.

Learn more in ACCELQ’s docs: Action Output Parameters · Configuring Parameter Sources in a Scenario · SAP GUI Automation Command Reference Guide

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Verify at three levels: step outcome, document content and follow-on effects.
Read document numbers from message variables; log them as evidence.
eCATT's GETGUI, CHEGUI and MESSAGE blocks show the pattern: read, check, rule-based messages.
Include negative tests; keep evidence focused on numbers, values and message IDs.

Three levels of verification

Capturing document numbers

Where SAP's own tools fit

Negative tests and evidence

Lesson check