As more and more companies are turning to automation testing to improve their software development process, it’s essential for beginners to keep certain things in mind. In this article, we’ll provide you with some valuable tips and best practices for automation testing, along with common mistakes to avoid. Read on to learn how to get started with automation testing and ensure your testing process runs smoothly

1. Notes on using Test Data on Automation Testing

Element Locators are an important factor in determining the stability of an automation test script. Many newbies often don’t care much about getting the locator efficiently, but just manage to make it run at that moment. However, just because an XPath works right away doesn’t mean it will work fine later. Especially when there is a small change on the application which affects the structure of XPath.

Investing time to learn about locators with the use of a good XPath will help a lot and also reduce the later repetitive fixing. Finding and fixing an XPath in particular or a locator in general is a tedious and time-consuming job.

In example 2 below, the given XPath is to find the same element, yet the first way is recommended. It uses the relative Xpath type. Based on Text, the ability to change Text is less than the ability to change the position order of HTML tags like in example 2.

2. Notes on preparing Test Data in Automation Testing

The preparation of Test Data (also known as the Pre-Conditions step) is also an important thing. Most of the script errors are caused by the locator, the rest is related to test data. Many testers often use available data for testing and do not prepare data yourself.

For example, when testing the search function, the tester randomly picks an existing product name to search. However, this way only brings temporary results with a lot of risks, because after a while the product name is changed or deleted by another person, and then the script will not find the product and thus return the feedback as Fail.

Creating data for testing ourselves will help us control the condition and ensure that we always have the right data, for example, in the scenario above, instead of randomly choosing a product name, we create a new product in advance to get the necessary data, or you can refer to some more ways to prepare data as below similar to the section below about restoring Test Data.

3. Notes on restoring Test Data for Automation Testing

Restoring Test Data (Post-Conditions) is just as important as the preparing step, for example, after executing a test case to change the password of an account successfully, we must take a step to restore the old value so that other tests that use the account (or that data in general) are not affected, similar to changing the permissions and status of the data to be tested.

Some ideas to restore data after running automation test script

• Always use the UI to restore after running the test (for instance, after creating an account and verifying successfully, delete that account on the web UI too). This way allows no need to interfere with the DB, it, however, will take time and make the script longer.
• If you have an API, you should call the API, if possible, ask the dev to write more APIs to use. This way is fast & safe, but the necessary APIs are required.
• Delete via SQL query. For example, creating a user with the username Novatesting, then querying that user according to the username to delete. This way requires the right to connect directly to the data and carries many risks.
• Take a snapshot of the whole Database before running the test, after the test is over, restore the DB. This way will ensure the DB is as clean as the original.
• No need to restore on the test environment if you don’t worry about junk data. This is not a good solution.
• Create a list of required queries first, run it (or have the DB admin run it) after running the test. Apply in case you do not have the right to execute on the DB, but you have to ask the DB admin to run the commands.

4. Note about dependencies between test cases

Test cases should be independent from each other.

For example, we have 3 test cases, then these 3 test cases should be independent of each other, if only one of the three is taken out, it is still possible to run, avoiding the tests that depend on each other and when running separately, the error is incorrect. If there is a constraint, it should be prepared as a pre-condition similar to the Test Data preparing step.

The interdependence also leads to a situation where if one test case fails, it will affect the other following test cases.

For example: There are 3 cases: Add, Edit, Delete. If the design is bound together to run in the order of Add > Edit > Delete, but when the Add case fails to add Data, the Edit case does not have data to edit and similarly the Delete case cannot find the item to delete.

5. Notes on using the Waits mechanism

For automation testing on Website, Mobile or Desktop, a stable Waits mechanism is required. Since we test them on a network environment , stability is relative rather than absolute. Moreover, the Elements are not ideally arranged as they can be slow, delayed, with effects, overlapping layers, etc. Therefore, if there is no good Waits, it will lead to frequent errors.

Of course, depending on what technology you use when doing Automation Test, it will be set up accordingly. As in Selenium, you should use the Explicit Waits form, for example.

Note that we do not use Waits in the form of Sleep or Delay hard waiting code or else the code is significantly slowed down.

======================

Those are suggestions which may help newbies of Automation test save time learning from errors and failures.

If you’re interested in learning more about automation testing tools, check out our article on the top tools for beginners. Additionally, to learn more about common mistakes to avoid in automation testing, check out our articles on the topic Automation testing.