Selenium and Sahi started as open source tools around the same time and from the same company. Both tried to solve the problem of UI automation and both have been successful in their own ways. But the resemblance ends there. Selenium became Webdriver and became one of the most popular free tools in testing. Sahi became commercial Sahi Pro and is successfully used in various organizations to automate complex UI's spanning web, desktop and mobile applications. Right from who the user of the tool is to whether the tool should be open source or commercial, there are various philosophical, technical and commercial junctures where Selenium and Sahi have diverged. Based on our journey of over 10 years, this talk reflects on those divergent decision points, the philosophy behind those and what their outcomes have been.

Team A's application is evolving fast. Team B is switching UI frameworks (jQuery to Angular). Team C is migrating an applet application to web. Team D is extending a web app to mobile. Can automation help in the following scenarios? Ideally it should.

When applications evolve, test automation code starts failing. If tests are not fixed quickly, automation code becomes stale and the whole suite becomes unusable.

Changes to applications follow specific patterns. Knowing these patterns helps create automation frameworks which can handle them easily. In this talk, through live examples, we will see various ways in which web applications evolve, how they break automation code, and how we can structure the automation code such that there is minimal change required to accommodate changes.