Designing an Test Automation Project

Test Automation is a continuous project, so when we start writing the code for the project we should keep this in mind. You can have a look at Steps to consider before you start writing test automation to have a view how you can start your project. I will discuss how we can design automation project in this article.

When we will design automation project we should keep in mind the following thing:

  • it is a continuous process
  • it should be easy to maintain
  • can be extended if needed, etc

Let’s discuss some points that we should think when we design an automation project. Please note that these are my thoughts and experiences, it may vary person to person, project wise, etc.

Change in One Place, Get Effect in Multiple Places

A common way to get elements in automation is by identifiers – id, name, xpath, etc. In an application same element can exists in multiple page. Example for such an element can be menu item, search field, etc. When our automation script do some test on these elements then we have to use such identifiers again and again in our script. Now consider that each time you are writing the following line when we are working with the element:

driver.findElementById(“my_element“);

When we write this it is absolutely ok and test will pass (considering you have written a valid test script). You can ask, then what is the problem with this? Now consider that developer changes the ID of the element to my_elem. When we modify it then we have to change my_element to my_elem in each place. Beside if your project is huge and same element have been used in test script then you need to change the id in so many places. If any chance you missed to change the id then test run will fail when try to find element with my_element.

In order to avoid such boring and risky task we can create an central place where we can put elements id in a map or enum. Following is an example of enum:

public enum AutomationElements {

MY_ELEMENT(“my_element”),

… ;

}

 

Now we can simply call the element name MY_ELEMENT whenever we need to use the element. So when developer changed the element we only need to change the id my_element in this place and test will run perfectly. This way we can save time and decrease any risk and boringness. Using such a central place for element id, name, etc makes the project more robust and easy to maintain.

Tips: Try to name elements so that one can understand for which module the element is. Example: COMMON_SEARCH_FIELD(“search”). Here one can easy understand that this is Common search field element. Another example can be LOGIN_USERNAME_FIELD(“username”). I think you already understand what it means – this is the username field of login page.

Make Utilities

When we write automation script it is common that we need to write same line of code to do some task in automation. For example:

  • look out for search field
  • click it
  • enter keywords
  • press search button to do search action.

Consider we write these line of codes in multiple places as we need to perform this action in multiple test cases. If we need to change any steps/action for the above mentioned actions then we need to do it at all the places we write these lines.

Now if we write a utility class for the module and write a method to perform such action then it will be easy to maintain the code. We simply need to call the function. If any change needed for the search action then we can simply change in the method and do not need to update and caller of this method unless we change parameters or method name.

Tips: If we have multiple modules and for each module we need to write different utilities then it will be a good idea to write utility class for each modules. For example: as search action is common for all modules we can write utility class named CommonUtilities and put search action there. For login if we need any utility class then we can name it LoginUtilities. In this way it becomes easy to maintain the methods in future.

Simplify Methods

When you write any method make sure each method perform one single task. This is because if your method do multiple tasks then it becomes tough to maintain that. For example your method do the following tasks – login to system and perform search. When there is any change in the application for any of this action then you need to make the change in the whole method though both of them are not changed. Beside this if there occurs any error it will be difficult to track the main reason of the error.

To avoid such problems and make your and your teammates life each it is a good practice to write methods in smaller chunk which will perform one single task. In our example we can write two different methods for login and search actions. If there is any error occurred during test run we can promptly know which method is giving the trouble and in case of update we can easily do that without thinking of whether other methods will break or not.

Tips: Simpler the method easier to maintain the code.

Manager file

If you automation project covers multiple modules and you write utilities for all modules in individual utility class then when you need to use different methods in a test then you need to import all the utility classes in your test class. Beside you need to remember which methods is in which class. To avoid such issues and maintenance hazards you can simply use a manager class for all utilities. The purpose of this class is very simple, it will simply make bridge between test classes and utility classes. Example is as follows:

CommonUtils.java

public class CommonUtils {

public CommonUtils(){

}

public String commonMethod1() {

………..

}

}

LoginUtils.java

public class LoginUtils {

public LoginUtils(){

}

public void loginMethod1() {

……………

}

}

UtilsManager.java

public class UtilsManager {

CommonUtils commonUtils = new CommonUtils();

LoginUtils loginUtils = new LoginUtils();

public UtilsManager(){

}

public String commonMethod1() {

return commonUtils.commonMethod1();

}

public void loginMethod1() {

loginUtils.loginMethod1();

}

}

Instead of importing LoginUtils and CommonUtils now you can simply import UtilsManager and can call the methods without bothering about the parent utility class for that method. Beside in test case class you need to import only UtilsManager instead of CommonUtils and LoginUtils.It becomes more easy to manage the test cases and utility classes. As I said design depends on person to person so this is an optional thing that can be implemented. I got good feedback and it made my project much easier when I introduced utility manager class.

Code Reuse

This is very import when you design your project. Try to write each methods in generalised way so that you can use the same code in multiple test cases and also in multiple projects. For example: again we think of login action. Login action is pretty much common in all application and I consider you have multiple projects to automate. You should write the login action in such a way that the code can be used from any test cases of intended project and also can be used in your other projects with tiny modification. In this way you can save a lot of work and time and thus it helps to speed up your project.

From my experience this concept really helped me a lot and speeded up my projects. I reused many utility method in different projects.

Follow best practices for coding

This is very important when comes coding stuff. There any many best practices for coding which really helps us to write clean and easily understandable codes. Some best practices are:

  • Method name self identifies the task it will do.
  • Writing comments.
  • etc.

Please do some R&D to know more about best practices for coding. Please try to follow best practices as this will help you in future.

Conclusion

Lastly I want to state that when you get task to do automation project, do not jump to start. Before start try to design the architecture of the project so that it becomes more stable and the project runs smoothly in future. You should design the project in such a way that it is easily scalable, reusable and easy to maintain. Remember Test Automation Project is a continuous process.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: