The document outlines a testing strategy for a subscription-based ticketing platform, emphasizing the importance of etiquette and constructive feedback during sessions. It includes a case study on the client's platform, which offers different subscription tiers for movie ticket booking, and highlights various types of testing and the tools used, such as TestNG and Gatling, for performance and end-to-end testing. The challenges faced during testing, particularly regarding data consistency and integration with third-party APIs, are also discussed along with solutions implemented to enhance efficiency.

1. Presented By:
Deepansh Gupta
Software Consultant
Test Automation Studio
Testing Strategy To Test
Subscription Based Ticketing
Platform

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Join the session 5 minutes prior to
the session start time. We start on
time and conclude on time!
Feedback
Make sure to submit a constructive
feedback for all sessions as it is
very helpful for the presenter.
Silent Mode
Keep your mobile devices in silent
mode, feel free to move out of
session in case you need to attend
an urgent call.
Avoid Disturbance
Avoid unwanted chit chat during
the session.

3. Our Agenda
1
01
What Is a Subscription Based Ticketing
Platform (Case Study Of Our Client)
2
02
Types Of Testing Performed
3
03
4
04
Tools Used For End To End Testing
5
05
Test Automation Framework
6 Demo
Challenges Faced During Testing

4. What Is A Subscription Based Ticketing Platform?
A subscription based ticketing platform has predefined plans and models for the customers.
The user can select a plan based on his/her need. Based on the subscription plan chosen,
customer will get a fixed amount that they can use to purchase tickets within a given period of
time.
They usually provide services where a user can select places within their vicinity and reserve
seating to avoid the hassle of buying tickets at the actual location.
Example of such a platform in India is BookMyShow. Their Filmy Pass is a discount offering
subscription which is valid for 50 days, where a user gets Rs. 75 off on 3 movie bookings.

5. Case Study Of Our Client
About
Our client is a subscription based movie
ticketing platform. They provide different
tiers (subscriptions) which grants the
customer a certain number of credits
that they can use to book tickets. The
user can book from home for some
partners, or go to the theater to reserve
for others
Idea Future
Currently the application is undergoing
beta launch in a controlled demographic to
see user response. Our client plans to
expand it to other areas within North
America post successful beta launch
Each show times for a movie will be
assigned different number of credits. This
will depend upon the popularity for a
show time. Weekend night show will cost
more than a weekday evening show. The
idea is to encourage users to select show
times that are not preferred

6. Types Of Testing Performed
Test the application and
its response time under
expected load
Test the core functionality
of our system
Test stability of
application with a new
build deployed
Test end to end
functionality from the
user perspective
Test application to
confirm existing
functionality is not
broken because of new
changes
A B
C D
E F
Functional
Testing
Smoke
Testing
Load Testing
E2E Testing
Scalability
Testing
Regression
Testing
Test application under
more than expected load
to identify breaking point

7. Challenges VS Solutions
VS
Data Validation
Huge amount of data means more edge
cases. One missing movie data could create
bad end user experience
Multiple Build Push
Multiple developers mean multiple pushes
to environment every day. Smoke and
Regression testing had to be rigorous
Third Party APIs
All of the data was coming from third party
APIs, meaning you cannot get desired
results with your performance testing
Automation Scripts
Write automation scripts to work on huge
database to find edge cases that would
have been lost with manual work
Smoke with CI/CD
Integrating automation scripts with CI/CD
helped us to identify build issues before
regression testing can begin
Optimize Ourselves
If third party APIs do not allow load test, then
decide a benchmark and optimize our own
code to achieve that goal

8. Challenges VS Solutions
VS
No Test Environment
Unavailability of a dedicated test region
means one environment being used by
everyone for testing
Inconsistency In Data
Multiple third party APIs mean variation of
data set between them. The test data would
be inconsistent
Tight Deadlines
More features to deliver in less time. With
more features, changes were frequent and
multiple rounds of testing need to occur
over same functionality
Common Ground
A common ground needs to be discussed
between client, front end and back end so
it does not hinder anyone’s testing
Keen Eye
During the first round of functional testing,
flush out all the inconsistencies with manual
testing to ease future automation
Efficiency
Determine what work can be easily
automated , and what needs manual
intervention. Make automation work for you
efficiently

9. End To End Testing Flow

10. r
Tools Used For E2E Testing
Tools
Postman
Manual testing
for APIs
CI/CD tool to
build and run
automation
scripts GitHub
Actions
TestNG
Automation
testing
framework
with report
generation
Rest
Assured
Automate rest
APIs using
JAVA
Test management
Test Link
Performance testing
tool
Gatling

11. Why TestNG and RestAssured?
● Provision to group multiple tests together in testng.xml file
● Easily integrated with Maven
● Annotations are easy to work with
● HTML report generation with ReportNG
● Attributes help to run tests as per priority eg.
DependsOnMethods
● With RestAssured, TestNg can be used to generate different
tests each calling different API. This way positive and
negative test cases can be covered easily and with proper
validation

12. Why Gatling?
● Real time monitoring can be done with dashboard
● Faster and easier setup
● Excellent reporting mechanism which is easy to understand and user
friendly as well
● Though the difference is negligible, gatling handles the load better as
compared to JMeter
● Good assertions to do basic validation with response. As our result was
cached, this was a key thing in our performance test.

13. CI/CD Integration With Github Actions
1. Different repository was created in github for automation code
to segregate the scala backend code from automation
2. Github workflow was created to run our script with
“workflow_dispatch” as its trigger
3. Another github workflow was added in our backend scala
repository which would trigger our automation github workflow
whenever there was a push to staging branch
4. This was done using github’s API to call another github
repository
5. This ensured that any new build pushed to our staging would
immediately go under smoke and regression testing
6. A github action was added in our workflow to send the html
report generated by testng over email with final result

14. Demo

15. Thank You !
Get in touch with us:
Knoldus Inc.
India, USA, Canada, Singapore, Netherland, Vietnam