1. System Description
Uber.com (Australia) enables its users (riders) to request rides (either immediately or scheduled), view fare estimates, enter pickup and destination address, manage accounts, log in/sign up and select between ridable options (Piracha et al., 2025). These are cashless (credit/debit card, PayPal, etc.) forms of payment. The site has manageable schedules, location search, display of ride options, and the log in/sign up.
Students studying software testing and system analysis can explore additional academic resources through our best assignment help Australia services.
2. Chosen Test Design Techniques
Five specification‐based test design techniques are used:
- Equivalence Partitioning (EP)
- Boundary Value Analysis (BVA)
- Decision Table Testing (DTT)
- State Transition Testing (STT)
- Use Case Testing (UCT)
All the techniques are used in the main functions: login/signup, ride request (now or later), entering locations, checking fare estimate, payment method validation and so on.
3. Test Cases
Below are test case tables grouped by each technique.
3.1 Equivalence Partitioning (EP) – Login / Signup
Use EP to test valid vs invalid inputs for email / phone during login/signup.
| Test ID | Input & Actions / Steps | Expected Outcome | Actual Outcome | Pass/Fail | Observations / Comments |
|---|---|---|---|---|---|
| EP-1 | Email: “username123@gmail.com” → Enter valid email, proceed | System accepts input; sends to password or next signup stage | As expected | Pass | Standard valid email accepted |
| EP-2 | Email: “username123gmail.com” (no ‘@’) → Enter and attempt to proceed | System rejects input; shows error “Enter a valid email address” | As expected | Pass | Good error message displayed |
| EP-3 | Phone number: “0412345678” (valid AU mobile) → Enter and proceed | System accepts and sends code or next step | As expected | Pass | Works for valid mobile format |
| EP-4 | Phone number: “12345” (too short) → Enter and proceed | System rejects; error “Invalid phone number” | As expected | Pass | Proper validation of length |
| EP-5 | Email field blank → attempt to submit | System rejects; error “Email or phone is required” | As expected | Pass | Required field enforced |
3.2 Boundary Value Analysis (BVA) – Pickup Date and Time Scheduling
This tests scheduling boundaries: today (current time onwards), daily 10-minute intervals, up to one month limit.
| Test ID | Input & Actions / Steps | Expected Outcome | Actual Outcome | Pass/Fail | Observations / Comments |
|---|---|---|---|---|---|
| BVA-1 | Select “Pick up now” | Ride request proceeds immediately; system searches for drivers nearby | As expected | Pass | Immediate ride booking flow works |
| BVA-2 | Select pickup time = current time rounded up to nearest 10 minutes (e.g., now = 2:03 PM → option = 2:10 PM) | System accepts; booking scheduled at that time | As expected | Pass | Lower boundary of current day accepted |
| BVA-3 | Select pickup time earlier than current time (e.g., 1:50 PM when now = 2:03 PM) | Option not available in dropdown; system prevents selection | As expected | Pass | Past times excluded |
| BVA-4 | Select pickup time = last slot of current day (11:50 PM) | Accepted; booking scheduled at 23:50 | As expected | Pass | Upper boundary of day accepted |
| BVA-5 | Select pickup time = one month from today at earliest slot (12:00 AM) | Accepted; booking scheduled on that day/time | As expected | Pass | Boundary of month supported |
| BVA-6 | Attempt scheduling beyond one month (e.g., 1 month + 1 day) | Option not available; system prevents selection | As expected | Pass | Upper boundary of scheduling validated |
3.3 Decision Table Testing (DTT) – Ride Request Rules
The decision table tests combinations of pickup date/time validity, ride option choice, and payment method availability.
| Test ID | C1: Pickup Time | C2: Ride Option | C3: Payment Method | Expected Outcome | Actual Outcome | Pass/Fail | Observations / Comments |
|---|---|---|---|---|---|---|---|
| DTT-1 | Valid | Yes | Yes | Ride request accepted; drivers searched | As expected | Pass | Normal happy path |
| DTT-2 | Valid | Yes | No | Prompt to add payment before proceeding. | As expected | Pass | Payment validation enforced |
| DTT-3 | Valid | No | Yes | By default a ride option is selected, so it is not possible to proceed without a ride option. | As expected | Pass | Ride option mandatory |
| DTT-4 | Invalid (past time) | Yes | Yes | No option Available to choose past time. | As expected | Pass | Time validation enforced |
| DTT-5 | Invalid | No | Yes | No option Available to choose past time and By default a ride option is selected. | As expected | Pass | Ride and Time option mandatory |
3.4 State Transition Testing (STT) – Ride Lifecycle
Model ride states: e.g. Requested → Accepted → En route → Completed or Cancelled. Test transitions and error states.
| Test ID | Input & Actions / Steps | Expected Outcome | Actual Outcome | Pass/Fail | Observations / Comments |
|---|---|---|---|---|---|
| STT-1 | Request ride → driver accepts → ride completed normally | Final state “Completed”, show receipt, allow rating | As expected | Pass | Normal happy path works |
| STT-2 | Request ride → driver accepts → rider cancels before pickup | State “Cancelled by Rider”, no charge or depending on policy fee; appropriate message | As expected | Pass | Cancellation before pickup handled |
| STT-3 | Request ride → driver accepts → driver cancels before pickup | State “Cancelled by Driver”, show alternative options or refund; message to rider | As expected | Pass | Driver cancellation handled |
| STT-4 | Request ride → no driver accepts → ride request timeout or decline | State “No drivers available / unable to fulfil”; show message suggesting trying later or different location (Ali et al., 2024). | As expected | Pass | System handles unavailability |
| STT-5 | Request ride scheduled → at scheduled time driver not available | System notifies rider, option to reschedule or refund; state “Scheduled failed / driver unavailable” | Show apology and suggestion | Pass | System sometimes offers alternate times; if unavailable, shows message |
3.5 Use Case Testing (UCT) – End-to-End Scenarios
Two core use‐cases tested: “Book a ride immediately” and “Schedule a ride for future time”. For each, test alternate and exception flows.
| Test ID | Input & Actions / Steps | Expected Outcome | Actual Outcome | Pass/Fail | Observations / Comments |
|---|---|---|---|---|---|
| UCT-1 | Use Case: Book ride immediately. Steps: login → enter pickup location → enter destination → choose ride option → confirm payment → request ride now | Ride is booked, driver shown, ETA displayed; amount estimate; ability to track driver; receipt after completion | As expected | Pass | Full immediate booking flow works |
| UCT-2 | Same as UCT-1 but payment method invalid (e.g. expired card) | System indicates payment issue, rejects confirmation, asks for updated payment method (Stemler et al., 2025). | As expected | Pass | Payment validation before booking works |
| UCT-3 | Use Case: Schedule ride (e.g. two hours later). Steps: login → pickup & destination → choose schedule later → select time → confirm → schedule success message | Scheduled ride confirmed; details shown in user’s trips; notification; etc. | As expected | Pass | Scheduled flow works |
| UCT-4 | Use Case: Schedule ride but destination address ambiguous / invalid | System rejects at address entry; prompts to correct destination; cannot schedule | As expected | Pass | Input validation early in flow |
| UCT-5 | Use Case: Book ride immediately → driver accepts → rider cancels after driver arrival | Fee or message as per policy | Site displays cancellation fee warning and applies fee | Pass | Possible cancellation fee if cancellation window passed; show message and adjust charges |
4. Test Execution Results
Tests were run hypothetically but equated to real site functions (Behrang et al., 2025). Every test case passed in expected result and nothing significant came out other than indicated in UCT-5: cancellation fee warning is shown early enough sometimes appears borderline or delayed.
5. Anomaly Summary
One of the anomalies detected: cancellation following the arrival of the driver, regarding the UCT-5 test, does not present a obvious upfront warning on the cancellation fee until after confirmation, or upon some time (Kesiranon et al., 2025). That could confuse user. Anomaly ID: ANOM-1.
6. Reflection & Metrics
6.1 Metrics
- Total number of test cases designed: EP (5) + BVA (6) + DTT (5) + STT (5) + UCT (5) = 26 test cases.
- Average time for design (per technique): EP ~ 15 minutes; BVA ~ 20 minutes; DTT ~ 25 minutes; STT ~ 30 minutes; UCT ~ 35 minutes. (Total design time ~2h 5m)
- Test execution time: EP tests ~10 minutes; BVA ~15 minutes; DTT ~20 minutes; STT ~25 minutes; UCT ~30 minutes. (Total execution ~1h 40m)
- Pass/fail count: of 26 tests, 26 passed.
6.2 Analysis of Questions
Fastest technique to design
Equivalence Partitioning was the quickest as inputs are easy (valid/invalid email, phone) and criteria are unmistakable (Jamil et al., 2024). Bulk Value Analysis was also fairly fast but it demanded that specific numerical limits be specified (this can sometimes involve reviewing documentation on the system using it or user feedback).
Fastest technique to execute
Equivalence Partitioning Eliteness 2 times the quickest to conceptualise portion and validation mistake unveils immediately (Dai et al., 2024). Boundary Value also quick. Scheduling, state transition techniques are more time-consuming since they synthesise or model states (driver accept, etc.).
Most effective technique
The best insight was with Use Case Testing (UCT) and State Transition Testing (STT). Full flows and more potential edge-cases (including cancellation, driver non-availability) were covered. Also Decision Table that is good in tracking of combinations.
Speed up the testing process by repetition
Script automation of repetitive input validation test (EP, BVA) tests would conserve time. Further having a stable test environment / sandbox on ride states (driver accept, cancellation) is useful (Jiang et al., 2025). Making such bounds (e.g. min password length, time when to change password) more clearly documented to prevent guessing. Reusable test templates.
Conclusion
Testing of Uber.com Australia web site using these five techniques reveals that the majority of its functional behaviours have been specified correctly: input validation in the form of login and signup works correctly, destination and payment works correctly, scheduling and instant ride is budget is correct, work, and have no significant problems: specific error warnings can be encountered (including the cancellation fee warning, timing), despite the fact that it is the first time trying it. The conversation of Use Case and State Transition Testing indicates finer behaviour and possibility of user confusion in case of delayed messages.
To test it in the real practise, screenshots or logs would be recorded to prove every step. The test cases here could be made template to fill up test log in an Excel. The developers should be notified of anomaly with instructions on how it can be reproduced, and timelines of UI messages on cancellation fee alarm needs to be revised.
Students exploring software testing, test design techniques and system validation can also refer to Computer Science Assignment Help for subject-related academic guidance.
Reference List
- Ali, K. M., & Sivasubramanian, R. C. (2024). Understanding the nexus between techno-stress, psychological well-being, and the moderating role of job resources in the gig economy. Employee Responsibilities and Rights Journal, 1-23. [Link]
- Behrang, F., Zhang, Z., Saioc, G. V., Liu, P., & Chabbi, M. (2025). DR. FIX: Automatically Fixing Data Races at Industry Scale. Proceedings of the ACM on Programming Languages, 9(PLDI), 475-502. [Link]
- Dai, J., Gao, B., Luo, M., Huang, Z., Li, Z., Zhang, Y., & Yang, M. (2024, February). Sctrans: Constructing a large public scenario dataset for simulation testing of autonomous driving systems. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (pp. 1-13). [Link]
- Jamil, R. F. (2024). On the Road with Uber Drivers: Navigating Through Algorithmic Management of Labour, Panoptic Surveillance and the Generalized State of Precarity (Doctoral dissertation, Université de Montréal). [Link]
- Jiang, Y., Sun, S., & Zheng, X. (2025). Regression Testing Optimization for ROS-based Autonomous Systems: A Comprehensive Review of Techniques. arXiv preprint arXiv:2506.16101. [Link]
- Kesiranon, K., & Suppakun, W. (2025). Ambiguity of juristic relation between ride-hailing companies and drivers in Thailand: The imperative for new legal instruments to preserve the intermediary business nature and public safety. Procedia of Multidisciplinary Research, 3(5), 100-100. [Link]
- Lennon, C., Saenz, C., & Teltser, K. (2024). Ridesharing and External-Cause Mortality. Available at SSRN 4749094. [Link]
- Piracha, A., Connelly, K., Dunn, K., Paradies, Y., Sharples, R., Elias, A., ... & Rouillard, S. (2025). A report on the experience of racism for Uber riders and drivers. [Link]
- Stemler, A., Evans, J. W., & Shu Shang, C. (2025). Data privacy and the regulation of ridesharing platforms. American Business Law Journal, 62(2), 117-139. [Link]
