We answer a question of why to generalize things and approaches in development, as well as in test automation. OOP is a good way to achieve good tests, but you do not have always experts or just good enough programmers who could then support your OOP and some complicated approaches introduced during that. Also in a company, you need a way to share achievements/common components. I will share how we started to develop XML2Selenium, which objections we had, how it transformed into a platform not depending even on Selenium, will show architectural aspects/paradigms inside XML2Selenium, what allows you to make your own frameworks if you need that.
I won't just advertise a product, but concentrate on real business cases and examples from a practice, which pushed us to create something new. I believe some ideas from what we achieved provides you with another look at how test automation could be organized. E.g. in XML2Selenium all artefacts, logs, screenshots, video is put on the server into a separate folder, and you are able to access that just through a web interface. Another good thing is an integration of some approaches from Test Management into XML2Selenium reports, which allows managers do not check a status in spreadsheets, but just use the same report.
I will show you how manual QA engineer without special programming experience could create complicated tests, handling complicated things in the app.