Updating an existing automation framework: [Best-Practices]

Brief about this discussion:

Initially, let us understand WHAT we(automation developers) update? and what is the tricky part there.

To have a basic understanding of automation framework-click here.

Mostly, AUT(Application under test) evolves on regular basis to gain edge on business competitors and to achieve business goals. Hence the framework associated with the application requires up-gradation.

Every framework is having their own coding style, naming convention, utility module, business logic, object repository and basic framework configuration. As automation developer, we should understand that anything that exists in our framework may changes. However mostly, the WebElements, business logic and Utility methods undergoes changes.

The tricky part is, the framework is used by many stakeholders (developers, QE, Automation developers, Tech lead, BA, SME, etc) on daily basis. Re-think about the effect of your change on the framework. It is important to keep your changes seamless, with minimum impact on the working part of the framework.

Best Practices:

Before touching the framework, one should have clear idea about the 
framework structure and functional workflow of AUT.
    1. Updating common methods: Golden rule is to keep your code short, simple and with high coverage (so that, it(your updates) can cover most of the scenario). The below will mostly help you to modify business logic and utility files.
      For example: Let application be XYZ.com with customer module. Now automate job history of a employee: understand the scenario, an end user may have no job history OR he may have 10 job history. Now we assume that we have an existing method to automate the job history (as mentioned below). But the constrains is that, it can enter only one job history.
      Please find the Java code below:

      //existing code
      public void enterEmpHistory( String companyName, Date startDate, Date endDate){
          //enter company name, start date and end date
      //New code:
      //Writing a new implementation of same method
      //method overloading
      //Change desc: this method can enter multiple job history based on a deciding parameter (count)
      //Calling: This method is called with different set of data with the count(may be from bdd-feature file)
      public void enterEmpHistory(int count, String companyName, Date startDate, Date endDate){
             //do nothing and exit
            // first set of element is filled using this
            // second set of element is filled using this
            // note: the web elements are different here
         //continue as many time required
           logger.INFO ("Count is not defined");}

      In C#, we use the concept of default parameter to smartly tweak the changes easily.

    2. Updating Object Repository: Objects are referred by multiple business logic. Changing existing WebElements may result in success of your current script  but may fail other script. It is always better to follow the below steps to update a repository:
        • Step-1: Identify the object to be updated.
      //Existing objects
      Public Static WebElement submitButton;
        • Step-2: Add the new element with name: “PreviousName_New”
      //New objects, with new id and naming convention
      Public Static WebElement submitButton_New;
      • Step-3: Use the element in the script you are working currently.
      • Step-4: Check the other scripts if they are working with the older element or is it failing:
      • Step-5: If other scripts are failing, then use the new element. Inform team about the global change in the WebElement. Later refactor the code to remove the duplicate elements from the repository.
      • Step-6: In case other scripts are passing with the old element then rename the new element with something unique.
    3. Comments: Update should have following justification,what are the changes, where are the changes, why is that changes implemented, related ticket number, author of the update, time stamp, version number. Hence is mandetory part of code review.
    4. Appending new code: Point that we have to keep in mind while inserting any new code in the framework: analysis to identify, is that code available in the framework or not(don’t create redundency)? and also, are we inserting the code under corect package , correct class file or not?
    5. Deletion of existing code: Never hard delete a code. Soft delete the code when ever required. Later ask someone experince to refactor the entire framework and hard delete those code. You never know what becomes useful!


Hope this will be helpful as a guideline for everyone who is working on an existing framework. Thank you.



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