Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Cases

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.).


General Edit Booking UI

Test ScenarioExpected Result
Verify that the Edit Booking UI displays correctlyThe Edit Booking page should load with existing booking details.
Verify that non-editable fields are disabledThe field should be disabled or show an error message.
Verify navigation from Edit Booking to Store Page when changing a packageThe system should navigate to the Store Page for package selection.

Editable Fields

Test ScenarioExpected Result
Verify editing the date of bookingThe booking should update with the new date.
Verify editing the time of bookingThe 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 editableThe updated special request should be saved.

3. Booking Constraints

Test ScenarioExpected Result
Verify package type cannot be changed for prepaid bookingsThe 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 changesThe system should adjust the PAX to meet the minimum requirement automatically.
Verify that the Decrease PAX button is hidden when at the minimum allowed limitThe Decrease button should disappear or be disabled.

4. Payment Handling

Test ScenarioTest StepsExpected Result
Verify that prepayment adjustments follow the correct rulesChange 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 before1. 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 rules1. Modify a booking where the "on-hold" amount increases. 2. Confirm the change.The system should prompt for additional payment.

5. Special Cases

Test ScenarioExpected Result
Verify editing the menu in a delivery orderThe system should allow menu changes within the given time frame.
Verify status tracking for delivery ordersA status tracking page should be available.
Verify a customer can edit their booking within 15 minutes of creationThe system should allow full edits within this time frame.
Verify that a customer cannot edit their booking after the allowed windowThe system should prevent edits and show an appropriate message.

Conclusion

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)? 🚀