Mohit Testing Module
Mohit Testing Module
✔️
The primary goal of testing is to ensure:
✔️
The system fetches ride fares correctly (Functional Accuracy)
✔️
The application performs efficiently (Optimized API Calls)
✔️
The UI is user-friendly and responsive (Usability)
There are no security vulnerabilities (Prevention of Data Leaks & Unauthorized Access)
💡
1. Functional Testing
Objective: Ensure all application features function as expected.
Verify that APIs fetch ride fares correctly from Uber, Ola, and Rapido.
Check if API response time is within an acceptable limit (e.g., less than 3 seconds).
Test API failure scenarios to ensure proper handling.
✅ Execution Steps:
Use Postman or Swagger API tool to manually test API responses.
Ensure API returns HTTP 200 (Success) status.
If API fails, analyze logs and error messages.
✅ Expected Output:
API successfully retrieves ride fares.
If API fails, user receives a proper error message (e.g., "Fares not available. Try again
later.").
Fare Calculation Logic:
✅ Execution Steps:
Fetch fares from the database and manually verify them.
Test multiple source-destination combinations.
✅ Example:
If Uber API returns ₹150 but the app displays ₹200, it indicates a bug that needs fixing.
✅ Execution Steps:
Select source and destination on the UI.
Compare API response with displayed fares.
Click on a selected ride option and verify redirection to the respective ride-booking app
(Uber, Ola, Rapido).
✅ Expected Output:
The fare comparison UI correctly displays prices.
Clicking a ride option redirects the user to the correct app.
c) System Testing (End-to-End Validation)
Objective: Validate the entire application flow under real-world conditions.
✅ Execution Steps:
Install and open the application.
Enter source & destination.
Compare fares and select the cheapest ride.
Click on a ride option and check whether it redirects correctly.
✅ Expected Output:
Accurate fare comparison UI.
Seamless redirection to the selected ride-booking app.
No noticeable performance lags.
2. Non-Functional Testing
a) Performance Testing (App Speed & Load Handling)
Objective: Ensure the application can handle multiple users efficiently.
✅ Execution Steps:
Use JMeter to simulate 100 concurrent users making fare comparison requests.
Measure server response time and ensure it remains under 3 seconds.
If response time exceeds 5 seconds, optimization is required.
✅ Expected Output:
API response time remains within the acceptable limit.
Database queries are optimized using indexes and caching.
b) Security Testing (Preventing Data Breaches & Unauthorized Access)
Objective: Ensure that no unauthorized user can manipulate fare data or access user
information.
✅ Execution Steps:
SQL Injection Test: Attempt to enter ' OR 1=1 -- in input fields to check for unauthorized
database access.
Authentication Test: Ensure that a non-logged-in user cannot access fare data.
✅ Expected Output:
System successfully blocks hacking attempts.
Unauthorized access is prevented.
✅ Example:
Bug: Uber API returns ₹200, but the UI displays ₹250.
Impact: Misleading fare information for users.
Priority: High
Status: Assigned to the backend developer for fixing.
5.5 Final Test Report & Sign-Off
Test Summary Report: