Maintenance is the biggest challenge every Automation Architect must learn to manage on a daily basis. Small updates in a few xPath or CSS locator properties is just part of the job. Now imagine this scenario: The latest application release has a new underlying architecture, resulting in 50 known Link elements to change to a Button class. Each element had at least four code references distributed in over 100 test cases. Only the login test is working!

The client is accustomed to getting regression test results in two hours. Historical maintenance has been, on average, just three element modification. How could we say the maintenance time to resolve 400 element references this round would take about two days?

Taking a chance we implement Dynamic Class Switching by extending the .Click method for every Link element. If the Link does not exist, we create a parameterized Button element description on-the-fly in code. In 90 minutes only three test cases are failing because of a newly detected defect.

Then we asked ourselves: How many of our repository elements could we identify programmatically? And could we also increase our execution speed? Thus starts the journey into the new Magic Object Model design pattern. If we could do that in VBScript, what other programming languages and tools could benefit? Selenium and Java? Pylenium? Cypress? See how any functional testing tool framework can lower maintenance time and increase execution speed with The Magic Object Model.