Forum Discussion

meenakshiyadav1's avatar
meenakshiyadav1
Contributor
5 years ago
Solved

How to create a low maintenance keyword driven framework

I am using Keyword driven framework where I am passing the object (Alias name of the object) and Keyword from excel file to my test. With every release, there are many changes in UI of the application so we update name mapping and update Alias names in affected test cases. But there are huge changes in UI this time and we will have to update large no. of test cases. How can I handle it smartly in the future? Is there a way that I do need to mention the entire Alias name in my script or excel sheet. Is it possible to just mention the logical name (Description)of the object and entire Alias name can be calculated during run time (just like it is done in QTP)? So that no matter how many changes I need to do in the name mapping file, I do not need to update each and every test step in my scripts.

 

Also, please suggest if there is any other way available to create low maintenance framework.

 

 

  • If you're changing your Alias every time you update the mapping, then you're using Aliases wrong.

    Let's take for example the following.

    Say I have an object on a web page mapped like so.

     

    NameMapping.Sys.browser.myPage.panel.table.cell.panel.panel.buttonOK

     

    Now, I'm just using the naming because this is sometimes how TestComplete auto-maps things. Typically, I'd recommend more detailed and direct names but you get the idea.

    Now, auto-mapping would then create the Alias like so.

     

    Aliases.browser.myPage.panel.table.cell.panel.panel.buttonOK

     

    However, this is unnecessary.  As a rule of thumb here in our environment, we don't create an Alias reference for an object unless it is directly needed or necessary within the test case.  So, let's say ONLY the first panel above is really relevant.  In TestComplete, you can alter the Alias to read like so

    Aliases.browser.myPage.panel.buttonOK

     

    and preserve the original NameMapping.  The test cases will then reference the Alias and everything is peachy.

    Let's say, then, your developers change the page so that one of those extra panels is removed so it's no longer necessary.  You can edit the NameMapping then to click and drag things around and then delete objects within the Mapped Objects part of NameMapping so you get the following.

    NameMapping.Sys.browser.myPage.panel.table.cell.panel.buttonOK

     

    By editing and manipulating the NameMapping ONLY, just by dragging things around, the object identification continues to work.  The Alias NEVER needs to change.  You can keep the Alias to be the same designation as much as you want.  You can edit, rename, update, change, etc., the mapping of an object in all sorts of ways and, so long as it continues to be referenced by the same Alias, your Alias never changes.

    So, in your situation, your Excel can continue to use the same Alias name for as long as it is still relevant.  You never need to update the Excel sheet.  Just update the Mapped Objects section of your NameMapping when the application changes.

    THIS is exactly what Aliases were created for... to make a low maintenance framework so you can change the underlying object identification factors without having to change how they are referenced in your actual test cases.

2 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    If you're changing your Alias every time you update the mapping, then you're using Aliases wrong.

    Let's take for example the following.

    Say I have an object on a web page mapped like so.

     

    NameMapping.Sys.browser.myPage.panel.table.cell.panel.panel.buttonOK

     

    Now, I'm just using the naming because this is sometimes how TestComplete auto-maps things. Typically, I'd recommend more detailed and direct names but you get the idea.

    Now, auto-mapping would then create the Alias like so.

     

    Aliases.browser.myPage.panel.table.cell.panel.panel.buttonOK

     

    However, this is unnecessary.  As a rule of thumb here in our environment, we don't create an Alias reference for an object unless it is directly needed or necessary within the test case.  So, let's say ONLY the first panel above is really relevant.  In TestComplete, you can alter the Alias to read like so

    Aliases.browser.myPage.panel.buttonOK

     

    and preserve the original NameMapping.  The test cases will then reference the Alias and everything is peachy.

    Let's say, then, your developers change the page so that one of those extra panels is removed so it's no longer necessary.  You can edit the NameMapping then to click and drag things around and then delete objects within the Mapped Objects part of NameMapping so you get the following.

    NameMapping.Sys.browser.myPage.panel.table.cell.panel.buttonOK

     

    By editing and manipulating the NameMapping ONLY, just by dragging things around, the object identification continues to work.  The Alias NEVER needs to change.  You can keep the Alias to be the same designation as much as you want.  You can edit, rename, update, change, etc., the mapping of an object in all sorts of ways and, so long as it continues to be referenced by the same Alias, your Alias never changes.

    So, in your situation, your Excel can continue to use the same Alias name for as long as it is still relevant.  You never need to update the Excel sheet.  Just update the Mapped Objects section of your NameMapping when the application changes.

    THIS is exactly what Aliases were created for... to make a low maintenance framework so you can change the underlying object identification factors without having to change how they are referenced in your actual test cases.

    • meenakshiyadav1's avatar
      meenakshiyadav1
      Contributor

      Thanks a lot tristaanogre for taking time out to answer my query and sharing this important tip. I was aware that we can shorten the name in Alias but it never occurred to me that this can be used to reduce maintenance work in the future.