How do I insulate testers from XPaths and other implementation details

LegacyForumLegacyForum Posts: 1,664 ✭✭
edited December 2016 in SOAtest
in web functional tests
SOAtest has a collection of features that will insulate users from XPaths.
  • Recording and playback: Testing scenarios are created using recording and playback; the user just needs to record the actions they wish to test in the browser and SOAtest will create the XPaths necessary to identify elements used during the test.
  • Modify tests from the rendered view: If an XPath used to identify an element becomes invalid for any reason (for example, the element moves or the text for the element changes), users can right-click the updated element in the rendered view and choose "Modify action to use <element>." No direct access to the XPaths is necessary.
  • Add validations from the rendered view: To verify that an element is present during a step in the test, the user may right-click the element in the "Browser Contents" rendered view, choose "Extract value from element" and follow the wizard to create the validation. The XPath is generated automatically.
Similarly, there are a number of ways that users can modify labels to more accurately describe what is being done in a test.
  • Renaming actions: Users can double-click any action in a scenario, un-check "User default name" and enter a more appropriate description of the action taking place.
  • Renaming test suites: Users can double-click any test suite in a scenario and change their name in the "Name" field to describe the steps contained in the test suite. Users can also add notes describing the test suite.
  • Customizing validations: All validations in SOAtest can be renamed and their error messages adjusted to describe what they validate. Double-click any browser validation tool, select the validation and adjust the Description and Validation Message accordingly.
Finally, there are a number of ways to re-use steps recorded in SOAtest:
  • Reference tests: Users can record and customize a sequence of common actions (such as logging in), save the test in one location, and re-use the test as part of any new test. Making changes to the original test updates all other tests that reference the test. An original designer can create tests with high-level functions (logging in, logging out, searching for a term, etc), and new testers can use references to these tests without needing to understand the details of how they function.
  • Create actions and copy-paste: If necessary, an original designer can create tests that execute a single action (for example, click on the "Status" header), give the action a descriptive name (as explained above). The original designer could create a library of these single actions which new testers can copy and paste together into a sequence of actions without needing to know the XPaths used to generate the actions.
Sign In or Register to comment.