Urban Scooter: Comprehensive Testing Project
October 2024
As the final project of my TripleTen Bootcamp, I undertook a comprehensive testing project for "Urban Scooter", a multi-faceted application designed to provide electric scooter rental and deliveries.
Project Overview
The project was divided into three main components:
Web Application
Customer rental and reservation system
Mobile Application
Courier delivery management
Backend API
Integrated with PostgreSQL database
Testing Scope
Web Application
- Input form validation
- Layout consistency
- User interface responsiveness
Mobile Application
- Functionality testing
- UI/UX evaluation
- Cross-device compatibility
Backend API & Database
- API endpoint testing
- Database integration verification
Testing Methodologies
Tools Utilized
Web Application Testing
Input Form Testing
I focused on stringent validation for key input fields in the "Who the scooter is for" form:
(click to enlarge)
The form included the following fields with specific restrictions:
(click to enlarge)
Additionally, I conducted exploratory testing to identify any potential issues with the layout of the UI while refering to the design guidelines on Figma.
View Figma Layout SpecsTesting Results
Total test cases: 123
Failed test cases: 21
Bug reports logged: 23
View Full Test ReportCritical Findings
Subway Station Selection Error
A critical TypeError was discovered when submitting the form via the Enter key after selecting a subway station.
Input Field Vulnerabilities
The system exhibited vulnerabilities across multiple input fields, including the first name, last name, and address fields. Similar to the address field issue, invalid inputs such as only dots ("....."), dashes ("---"), spaces (" "), and commas (",,,,,") were incorrectly accepted as valid. While these characters were allowed as part of valid inputs, the system erroneously permitted them to be entered alone, without any valid accompanying characters, bypassing the required validation checks.
Mobile Application Testing
Mobile App Testing
The mobile application is designed for couriers to accept and complete deliveries of orders placed by clients through the web application:
Testing this component required integrating several parts. For each test, I accessed the backend API to create a courier account, generated an order through the frontend web application, and linked everything together within the courier mobile app. The tests were conducted using the Android Studio emulator, specifically with API version 31 on a Google Pixel 6.
The Urban Scooters mobile application underwent extensive testing to evaluate its functionality, user interface, and performance across various conditions. A total of 28 test cases were executed, covering a wide range of scenarios typical users might encounter.
Areas of Focus
1. Notifications
A notification is triggered when there are two hours left to complete an order. The notification includes the text similar to: "2 hours to the end of the order. The order 'State St 1214' must be completed before time X."
2. Lack of Internet Connection
A "No Internet Connection" pop-up appears when the user taps any active button with no connection. This pop-up only disappears when the "OK" button is tapped.
Once again I refered to Figma designs to identify any potential issues with the layout of the UI.
View Figma Layout SpecsTesting Results
Total test cases: 28
Failed test cases: 9
Bug reports logged: 11
View Full Test ReportCritical Findings
Notification System Failure
All six notification tests failed, indicating a significant issue with the app's notification functionality.
Internet Connection Pop-Up Issues
The app displayed the "No Internet Connection" pop-up in most cases when users attempted to perform actions offline, but it did not appear on the login screen, and the pop-up could be dismissed by clicking outside of it.
API Testing
Purpose and Objectives
The goal of this testing process was to ensure the /api/v1/courier API endpoint functioned correctly. Specifically, the tests aimed to verify that couriers could be created, authenticated, and deleted according to the API's requirements, with all changes accurately reflected in the database.
Objectives:
- Functional Validation: Ensure that the API correctly handles the creation, deletion, and login of couriers.
- Boundary and Negative Testing: Test the system's response to inputs that push boundaries or are invalid, and confirm that inappropriate inputs are rejected.
- Database Integrity: Validate that the API's actions are properly reflected in the PostgreSQL database, ensuring no data corruption or inconsistencies.
API Endpoints Tested
POST /api/v1/courier
This endpoint registers a new courier. It accepts:
- login: A unique username.
- password: A secure password that is hashed before being stored.
- firstName: The courier's first name.
Expected Behavior: A successful POST request should create a courier in the database, ensuring the login is unique. Duplicate or invalid data should result in an error.
DELETE /api/v1/courier/:id
This endpoint deletes a courier by their ID. Upon successful deletion:
- The courier's record should be deleted from the Couriers table.
- Any associated orders in the Orders table should also be deleted.
Expected Behavior: Both the courier and their linked orders should be removed from the database.
POST /api/v1/courier/login
This endpoint handles courier authentication.
- Valid credentials should return a session token.
- Invalid credentials should return an error.
Testing Process
Tools and Resources Used:
- Postman: Used to execute requests for creating, deleting, and logging in couriers, allowing validation of the responses for each test case.
- Swagger API Documentation: Provided crucial information on the API endpoints, expected input formats, and error handling.
- PostgreSQL Database: Connected via SSH to verify the results of the API tests, running SQL queries to ensure that the expected changes occurred.
Executing Test Cases:
For each API endpoint, the following steps were followed:
- Sent a request using Postman with valid or invalid inputs.
- Verified the response status (e.g., 201 Created, 400 Bad Request).
- Queried the database to ensure the expected changes occurred.
- Tested edge cases, such as input fields with minimum or maximum character limits.
Critical Findings
Orders Not Deleted After Deleting Linked Courier
The most significant issue discovered during testing was the failure to delete linked orders after a courier was removed from the database:
- Issue: Deleting a courier did not remove their associated orders, leading to orphaned records.
- Impact: This failure poses a significant risk to data integrity, potentially causing confusion in order management and complicating future data retrieval.
Input Validation Issues
Validation issues were discovered during testing:
- Invalid inputs were allowed, leading to improper records being created.
- Couriers were created with unacceptable values, including symbols, non-latin characters, and numeric values.