Best practices | Scanning | Identifiers

Let's get into technical details for a moment. When you scan your application to create Modules, you select identifiers for your screen elements. These screen elements are called controls. At runtime, Tosca uses the identifiers you chose to find the controls you want to test. This topic explains the different identification methods and when to use them. We also have some tips and tricks to keep your identifiers unique and stable across tests.

Identification methods

Tosca offers different ways to identify controls:

  • By property, where you identify a control by its technical properties in the application code. Typically, properties are the fastest and easiest way to identify controls. We recommend that you always try this method first.

  • By index, where you identify a control by its position in the index of a page. It's a good solution for controls that exist in multiple places on the same screen.

  • Via anchors, where you identify a control by its location relative to other controls ("anchors"). We recommend that you use anchors only for non-web applications. In a modern web context, it might be too difficult to find anchors that are consistently stable.

  • Through images, where you identify a control by one or more screenshots. We recommend this method for controls where nothing else works.

Tips and tricks

No matter which identification method you choose, all identifiers must meet these criteria:

  • They're unique to the control. If they aren't, Tosca can't find the right control at runtime, let alone steer it.

  • They're stable. If they aren't, Tosca might find the control, but not in every test run. In the worst-case scenario, the identifier only works once, during the scan. All in all, unstable controls result in unstable tests and inconclusive results.

Make controls unique

To make controls unique, try these things:

  • Select multiple properties to create a combination that's unique to a control.

  • If you can't find a workable combination of properties, use a parent control for identification. The parent node might have a unique ID, which also makes the control itself unique. Select the parent node first and then the control itself.

    By the way, the right parent might not be the control that's directly above in the hierarchy. To find the right parent, turn on Highlight Selection in the XScan Advanced View and move through the parent nodes in the scan window. XScan then highlights the respective section in your application.

  • If your application loads a pop-up as part of a page, you might also have to use a parent for identification. A good example are embedded pop-ups in Salesforce. The controls in the pop-up might be unique within the pop-up itself, but not within the whole screen. In this case, use the pop-up's top-level container for identification. For example, with the properties ClassName or InnerText.

  • For image-based identification, use more than one screenshot to identify a control. This is especially important if controls don't always look the same. For instance, text boxes with changing content. If a text box has a static label, make sure to add a screenshot of the label. A toggle button is another good example. Add screenshots of both states, so Tosca recognizes the control in both ON and OFF mode.

Make controls stable

To make controls stable, try these things:

  • Watch out for dynamic values and fix them with a * wildcard. Let's say that a property adds a hit counter at the end of its value: Example property value_20. This means that the property value is only valid for the current session. At runtime, the hit counter will be at least 21, but Tosca's looking for a control with 20. To avoid this, change the property value to Example property value*.

    One of the more common troublemakers is the Caption property, which often has session-based information, such as numbers or search terms. You need to fix that with a wildcard, or Tosca won't find the window or tab.

  • Double-check user permissions. Some users have elevated permissions, which means they see controls and properties that other users don't. Make sure that the Windows user under which Tosca runs your tests has the same permissions as the user who scanned the application.

  • For index and image-based identification, consider the state of your implementation. How much change do you still expect?

    Adding or removing instances of a control changes the index. If that happens after the scan, Tosca won't find the right instance at runtime.

    And if you change the design after the scan, Tosca won't find a match for the screenshot you use as an identifier.

  • For image-based identification, consider screen resolution, color depth, or scrolling. Make sure that the Windows user under which Tosca runs your tests has the same settings as the user who scanned the application. Alternatively, you can add multiple identifying screenshots in various resolutions and/or color depths. However, this increases test execution time. At runtime, Tosca searches for a match for the first screenshot. If Tosca can't find a match, it moves on to the next screenshot, then the next, and so on.

What's next

If you haven't yet, check out our other best practices articles.