"Are you working for a product where you're struggling to automate the module(s) which you actually think can not be automated?"
Considering you have a product running on different browsers, different OS and/or different platforms and for this, you have written automation scripts in different technologies. So, following are the pain points which we are going through: -
Automation candidates test-scripts can’t be automated
Lower automation coverage
Lesser auto-tests => more manual work.
Lessor auto-tests => more regression time.
No with-in sprint automation.
Urge for the quick solution to cater to cross-technology and cross-platform automation scripts.
So, based on the above points, we came up with the automation architecture in such a way which serves the purpose in the following manner:
Able to add more automation coverage in another layer of testing.
Able to make a call from any platform (mobile or web) with any technology like Java, Swift, C#, etc.
More automation coverage = Lesser manual effort during regression or Smoke testing.
Application: Responsibility: Application is the main Spring Boot Application and has the following responsibilities:
Controllers: Responsibility: Controllers are the Rest Controllers has the following responsibilities:
For restful services creation for CRUD operations
All the requests and response from the external automation framework is being catered via controllers
Services: Responsibility: Services is the Business Logic layer where the CRUD operations can be performed based on the extended web-service calls. These operations can be performed on the product’s existing APIs and/or database using the data-access layer, below are the key responsibilities:
Business use-case based CRUD operations on the product database
Business use-case based CRUD operations on product existing web-services
Authentication of the product can be done internally via services based on credentials supplied from the controller params.
DAO: Responsibility: DAO is the Data Access Layer where the CRUD operations can be performed on the product database.
Some of the actual problems and the solution:
Problem#1: Alerts - Dismiss for Today flow
We have to wait for 24h to verify that the alerts section is displayed again
Cannot run the same test on both platforms (web/mobile)
Cannot run the same test twice in the same day
Solution: Unsupress the suppressed dialogue box by calling the extensive API can resolve the problem so that on re-run the automation it would not fail.
Problem#2: Tasks read status, once selecting a task, it is marked as read and cannot check it again.
Solution: Unread the task with simple extensive API call with taskId as a parameter
Implementation and usage
We have the implementation done on a product, and is utilized by 4 external automation frameworks, as below:
API Automation Framework (Java)
Web Automation Framework (.Net)
Android Mobile Automation Framework (Java)
iOS Mobile Automation Framework (Swift)
We can walk through with the implementation approach, as a
Producer: How we actually produce the HTTP response for a test scenario via API call requested by the consumers.
Consumer: How our consumers (external automation framework) can get the HTTP Response, they can use at their end to get the work done.
Time break-up and the speakers:
Introduction about the case-study 3min - Sahib
Problem and solution 5min - Amrit
Architecture diagram walk-through 5min - Sahib
Demo 5min - Amrit (running the demo) / Sahib (explaining the demo)