Feature: Edit Booking UI Redesign
Objective: Ensure the new Edit Booking functionality works as expected, allowing users to modify bookings while respecting constraints (e.g., prepayment rules, package limits, etc.).
Test Scenario Expected Result
Verify that the Edit Booking UI displays correctly The Edit Booking page should load with existing booking details.
Verify that non-editable fields are disabled The field should be disabled or show an error message.
Verify navigation from Edit Booking to Store Page when changing a package The system should navigate to the Store Page for package selection.
Test Scenario Expected Result
Verify editing the date of booking The booking should update with the new date.
Verify editing the time of booking The booking should update with the new time.
Verify editing the PAX (number of guests) The PAX should update accordingly, following package constraints.
Verify special requests & occasions are editable The updated special request should be saved.
Test Scenario Expected Result
Verify package type cannot be changed for prepaid bookings The system should prevent the change with an appropriate error message.
Verify package change with a higher-priced package (allowed) The system should allow the change and prompt for additional payment.
Verify package change with a lower-priced package (not allowed) The system should prevent the downgrade with an appropriate message.
Verify PAX constraints for package changes The system should adjust the PAX to meet the minimum requirement automatically.
Verify that the Decrease PAX button is hidden when at the minimum allowed limit The Decrease button should disappear or be disabled.
Test Scenario Test Steps Expected Result
Verify that prepayment adjustments follow the correct rules Change a booking where the new total is higher than the previous amount. Check if the additional amount is correctly charged. The system should require payment for the difference.
Verify that no refund is given if the new amount is lower than before 1. Change a booking to a lower-cost package. The system should not issue a refund but maintain the original amount.
Verify "On-Hold" payment adjustment follows correct rules 1. Modify a booking where the "on-hold" amount increases. 2. Confirm the change. The system should prompt for additional payment.
Test Scenario Expected Result
Verify editing the menu in a delivery order The system should allow menu changes within the given time frame.
Verify status tracking for delivery orders A status tracking page should be available.
Verify a customer can edit their booking within 15 minutes of creation The system should allow full edits within this time frame.
Verify that a customer cannot edit their booking after the allowed window The system should prevent edits and show an appropriate message.
These test cases ensure that:
The UI works as expected and displays the correct elements.
Users can edit only allowed fields , while restricted fields are enforced .
Booking constraints and rules (e.g., prepayment, package limitations) are correctly followed.
Payments and adjustments function properly.
Special cases (e.g., delivery, dine-in, time-based restrictions ) behave as required.
Would you like additional negative test cases (e.g., invalid inputs, edge cases)? 🚀