Identifying controls

An automated test is only as stable as the way it finds things on the screen. A recorded script addresses every field by its full ID path. That works on the day of recording and often breaks later, when a screen variant hides a field, a subscreen moves, or a table shows rows in a different order. This lesson separates stable ways of addressing controls from fragile ones.

Two ways to find a control

The first way is by ID path: ask the session for the object at a known ID such as wnd[0]/usr/ctxtVBAK-AUART. It is fast and precise. The second way is by searching: walk the children of a window or area, or search by name, and match on properties such as the control's type, its technical name or its label text. Searching is slower and needs more code, but it survives changes in the path above the control.

What makes an address fragile

• Connection and session indexes. A path that starts with con[0]/ses[0] fails when a tester has two systems or sessions open. Attach to the right session explicitly, by checking system, client and user.
• Subscreen and container names. Many transactions build screens from subscreens whose container names appear in the ID. A different order type, screen variant or transaction variant can change them.
• Tab positions. Tabs can be hidden or reordered by configuration; select a tab by its name, not its position.
• Row indexes. "Row 3 of the item table" is a fragile idea; row positions change with sorting, filters and scrolling.
• Language-dependent text. Labels and button texts change with the logon language and with releases.

Tables and ALV grids

Tables are where most GUI automation breaks. SAP GUI has two families. A classic table control (for example the item overview in many dynpro transactions) shows a limited number of visible rows; the cells are addressed by column and visible row, so after scrolling the same row index points to a different item. An ALV grid is a control inside a container (the ID typically passes through a custom container and a shell), and its cells are read by row number and the column's technical field name; check the API reference for your SAP GUI version for exact method names.

The same idea applies to table controls, with one extra step: they only expose visible rows, so the script must scroll and keep searching until the key is found or the table ends. Many teams wrap this in a single, well-tested helper, "find row where column X equals Y", rather than repeating it in every test.

Keep locators in one place

The ISTQB test automation syllabus recommends the page object model: keep each screen's locators in one class or module, so that when the screen changes you update one place instead of every test. For SAP GUI, a "screen object" for VA01's initial screen holds the IDs for order type, sales organization, distribution channel and division, plus methods such as "enter sales area". Tests call those methods and never contain raw IDs.