Test Automation — A product or just a Framework ?
Hey ya !! I thought of sharing my journey from a “Test Automation Framework” to “Automation Platform”. This may benefit to others, exploring similar stuff.
I have seen a lot of people spending quantitative time on developing test automation framework and eventually ending up having a framework which caters ONLY a specific type of cases and then people tend to develop either a Separate framework for App & Web or a common framework supporting Separate cases for App & Web. Usually this framework may have various components like Object Repository (page source definitions storage), User Actions Definition (a JAVA/Python code), Test Data (csv/Excel etc.) and Business Logic (again a code) etc. Automation code picks up data and objects from respective components and executes the desired test cases. Overall picture may look like this:
Well, I also started writing framework just like others, creating lengthy classes, all test data coupled in code along with actions, though maintained a separate a Object Repository in excel sheet. Well with the passage of time, I realised that keeping data coupled with code, can’t be scaled further because of difficulty in consuming the data dynamically. Eventually I had to refactor a lot of code again to enhance the scalability. By then, the architecture became something like this:
Well I was proud of this approach until I encounter a situation when I ended up having a bulk of cases with almost similar user journey but on different platforms (app/web).
And then I realised even if a single framework covering all platforms — desktop web, mobile web and mobile apps altogether, may not still, be an ideal candidate because this can’t execute a case having a user journey common to multiple platforms like “purchase a product on amazon app and web”.
A Big Problem — Redundancy of User Journeys:
Now question is — why do I need to worry about common user journey? Well, as the application grows, user journeys (Test Cases etc.) also grow and thus the automation coverage. Most of the journeys (specially for an eCommerce company) on different platforms like web, app can be similar, therefore its very important to reuse the journeys across platforms else the automation cases will have lot of redundancy and least re-usability.
Lets take an example of Nykaa or Flipkart. Nykaa has three consumer facing applications nykaa.com, nykaaman.com and nykaafashion.com, similarly Flipkart has flipkart.com, myntra.com and jabong.com. Now most of the high level user journeys are same on all of these platform like “Buy a product from URL: https://www.nykaa.com/makeup/face/face-primer/c/233". This journey will work on app (via DeepLink) and web in nykaa. But due to the changes in Html Locators and Test Data or sometimes in user journey, I have to write the same cases separately for all of the above domains and platforms (app / web).
Solution To Portability — “Automation as a Platform”:
If you look at the problem closely, there is an inbuilt simple solution. On a high level, lets say if I decouple all the dynamic components (application specific components) like Objects & Test Data then rest everything else stay as is. Will that work ?
Store Test Data and Page Objects separately in a DB, preferably NoSql like MongoDB or so. Make this dynamic data (objects and test data) available to framework On Demand via REST API / Services at the time of execution. Before creating the user journey, create the granular and reusable modules and use these modules in forming the User Journeys (Flow) or Test cases. Now these modules can also be specific to application. With this, all application specific things moved to Services and reusable modules. Once we start executing this, test case will get all the requisites (objects, data etc.) dynamically and same case will execute on all the platform. That’s how I achieved Automation Platform.
Let me know if you need any assistance achieving this. Happy to help !!
Thanks for reading.
Pankaj Kumar Katiyar