Basic rules

Keep it short, keep it simple, reduce dependencies, stress re-usability and clean up when you’re finished!

Do not overload the scripts!

Focus on the (one) key purpose of the test case. It is better to create a lot of short scripts than only a few large test cases covering too many features to test. This helps to maintain and debug the scripts and it is also much easier to locate the root cause of real problems if a test case fails.

Do not test the same feature again and again!

If possible, do not test the same feature again and again in several test cases but find the shortest way to get to a specific page! For example when testing different shopping bag or checkout features in several test cases, try to avoid searching product and browsing to product detail page. Instead, start the test case with opening the product detail page directly. In case search does not work, only the test case covering search will fail. If search is used in all the test cases, all of them will fail and debug is needed to find out what’s wrong.

Use modules to perform repeating sequences!

If you realize that you’re recording an identical sequence of several commands more then once, then think about extracting it to a module. Not only does it save you time when creating the test cases but also makes maintenance much easier. Adjusting an xpath then only has to be done once in the module instead of repeating fixes in each single test case script. Typical sequences that have to be done in many test cases and are worth a module are logging-in or adding products to cart.

Be consistent in using the modules you created!

For example, do not perform login using the module in some test cases and without using the module in other test cases. You will lose control!

Name your actions!

The automatically generated action names are not very helpful when analyzing reports or test results. Edit the action names immediately after recording as long as you can remember. Do not use the same action name for different actions.

Add comments to your script commands!

Write comments to document the purpose of each command as long as you can remember. At least describe the target element addressed by the command with a clear name. Reading and understanding a test case script for maintaining or debugging purpose can be tricky if you just see click("xpath=/html/body/div[3]/div[2]/div/ul/li[2]/a"). It definitely helps to read a comment like Click ‘Login’ button.

Clean up at the end of your test case!

For example, after adding products to cart or addresses to address book make sure that the test case itself does remove them at the end. make sure each test execution starts under identical conditions. Validations may fail for the second test run if the previous one did not clean up all artifacts.

Be prepared if the previous test run did not clean up and add some randomization where needed!

Test cases may fail because they try to add something that is already existing. The test case might add something during a failed test run that has not been finished (and therefore the clean up at the end of the test case has not been performed). Replace object names or list entries with a macro like ${RANDOM.String(4)} to get a random string of four characters. Even in case the clean up did not work properly, the next execution has at least a chance to pass.

Use robust xpath expression!

Xpaths or generated IDs are likely to change. To avoid test case maintenance after a new build of the tested application you should rework the recorded target element locators directly after recording. For example for the cart link, instead of html/body/div[3]/div[2]/div/ul/li[5]/div/div[3]/div[1]/div/a
you should better use something like //div[id=‘cart’]/div1@. XLT Script Developer 4.1 offers a nice new feature to select one of several possible xpaths from a list in command edit window after executing the command and also allows to avoid specific element locators while recording.

Do not let your test cases end with a clickAndWait command!

In the context of test automation this doesn’t make sense without any validation/assertions. For example, in most cases it is not necessary to close dialog windows or returning back to start page at the end of the script. If you want to check if e.g. a ‘Back’ button is existing then it is enough to validate this and that’s it. You don’t need to click it. This can save significant time during test execution because it saves you a lot of page loads. If it is necessary to check if returning to home page works as expected, then you have to add some assertions after the last clicAndWait command.

There are exceptions from this rule of course (let your test cases end with a clickAndWait command!): If you clean up, then clicking a ‘Delete’ button as the last command could make sense. Also if it’s necessary to log-out, then clicking the log-out link as the last command is acceptable. But again: Why not add an assertion that makes sure that you were successful with that click?

Be patient and wait… (forElementPresent)!

clickAndWait waits for the page being loaded completely. But today’s dynamically created web applications are full of JavaScript that is adding elements to the page even after the page is loaded completely. If adding an assert, click or select command directly after the clickAndWait, you will likely face race conditions and success of the test case is depending on replay speed. The first command after a new page has been loaded should always be a waitFor…