Level of detail and audience

The same order-to-cash test can be written in eight lines or in eighty. Neither is wrong in itself. The right level of detail depends on who will run the case, how risky the process is, and how often the user interface is likely to change. Getting this wrong in either direction costs the project: too little and new testers guess, too much and every screen change breaks the script. Start by asking who will actually read the case. On an SAP program there are usually four kinds of reader, and each wants something different from the same document.

Write for the least experienced reader who will realistically run the case, not for yourself. At Contoso, that is the internal regression team after hypercare, so Priya sets the default level at "a capable business user who has never run this process in S/4HANA". The test level matters too. A consultant's unit test of a pricing procedure can be terse because the consultant is also the reader. A system integration test that crosses sales, warehouse and finance needs more context, because no single tester knows every module. User acceptance testing needs business language above all, because the key users are judging whether the process fits how Contoso works, not whether a screen behaves.

Intent-level steps with targeted field detail

A practical pattern is to write each step as a business action, then add field-level guidance only where a field is the point of the test or is easy to get wrong. Compare the three versions of one step below. The third tells the tester what to achieve, highlights the two fields that matter, explains why they matter, and leaves routine navigation to the tester. A new tester can still look up the navigation in the job aid or the process training material, which is maintained once for everybody instead of being copied into every script.

• Too thin: "Create the order."
• Too thick: "Click field Sold-To Party, type 17100001, press Tab, click field Ship-To Party, type 17100001, press Tab, click field Cust. Reference, type PO-5531…" (and so on for 25 fields).
• Right: "Create a standard sales order for the customer and product in the data set, sales area 1710 / 10 / 00. Enter the customer reference from the data set (it is printed on the invoice and checked in step 6). Leave pricing date blank so it defaults to today."

Screen-agnostic wording for Fiori and SAP GUI

On an S/4HANA Private Edition or on-premise program the same action can often be done in a Fiori app or an SAP GUI transaction; the sales order can be created in Manage Sales Orders or with VA01. If the step text embeds one UI, the case breaks when the project switches, or when a tester uses the other route. Put the business action in the step and the entry point in a separate column or field: "Where: Manage Sales Orders app (or VA01)". In SAP S/4HANA Cloud Public Edition, users work almost entirely in Fiori apps, so name the app and its business role. Avoid describing button positions, colors or screen coordinates. Use the label a user sees, and accept that labels can vary slightly by release and personalization. If a field's position matters, it is usually because of a configuration choice, and that belongs in the expected result, not the step. The same thinking applies to what the tester should look at. "Check the net value on the item" works in both UIs; "check the third column of the item table" does not. Where a check really does depend on the UI, for example a Fiori app that shows a status as a colored indicator while the SAP GUI transaction shows a text, say what the status means in business terms and let the tester read it from whichever screen they use.