# QA Test Suite — React Web Source: QA sheet pasted 2026-09-10. Columns preserved from the original (`Dev Check`, `QA Status`, `Actual Result`, `Remarks` left blank to fill in). > **Incomplete.** The paste was cut off by a message size limit part-way through > **TC_119** (Surge Price). Everything from TC_119 onward is missing except the > ETA block, which arrived in a separate message and is included at the end. > > **Environment note.** The test data references zones (`Dhaka North #101`, > `Chattogram Central #102`, `Sylhet East #103`, `Khulna South`) and stores > (`Spice Hut`, `Fresh Mart`) that do not exist on `6ammart-dev.6amdev.xyz`. > These cases need the QA environment with that admin configuration. ## Contents - [1. React Web → Zone Impact](#1-react-web--zone-impact) — TC_01–TC_66 - [2. Delivery Management](#2-delivery-management) — TC_67–TC_93 - [3. Additional Delivery Charge](#3-additional-delivery-charge) — TC_94–TC_115 - [4. Free Delivery Setup](#4-free-delivery-setup) — TC_116–TC_118 - [5. Surge Price](#5-surge-price) — TC_119 (truncated) - [6. ETA](#6-eta) — TC_226–TC_252 ## 1. React Web → Zone Impact ### Zone Setup → Zone Availability & Visibility | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_01 | Verify only fully configured active zones are available for customer location selection | Dhaka North (#101): Food module + delivery charge rule + ETA all configured and enabled | Only the fully configured active zones are available when the customer sets a delivery location. | ☐ | | | | | TC_02 | Verify a zone with no connected module is not available to the customer | Zone 'Khulna South' created without connecting any module | The zone is not available and the customer cannot browse any content for that location. | ☐ | | | | | TC_03 | Verify a zone with no delivery charge rule is not available to the customer | Sylhet East (#103): Food module connected, no delivery charge rule configured | The zone is treated as unavailable and no store or module content is displayed. | ☐ | | | | | TC_04 | Verify a zone whose ETA configuration is not set up is not available to the customer | Chattogram Central (#102): Food module + delivery charge rule configured, ETA not set up | The zone is not activated and the customer sees an empty/service unavailable state. | ☐ | | | | | TC_05 | Verify a zone whose ETA configuration is turned off is not available to the customer | Turn the ETA setup status OFF for Chattogram Central (#102) from the admin panel | The zone becomes unavailable and the customer sees an empty/service unavailable state. | ☐ | | | | | TC_06 | Verify a zone whose delivery rule status is turned off is not available to the customer | Turn the delivery charge rule status OFF for Chattogram Central (#102) from the admin panel | The zone becomes unavailable and the customer sees an empty/service unavailable state. | ☐ | | | | | TC_07 | Verify a deactivated zone is not available to the customer | Turn the status toggle OFF for Dhaka North (#101) from the admin panel | The zone is not available and no store of that zone is displayed. | ☐ | | | | | TC_08 | Verify an appropriate empty state message is displayed when the selected location has no available zone | Set delivery location to 'Cox's Bazar' (outside any active zone) | A proper 'service not available in this location' message or empty state is displayed instead of a blank page. | ☐ | | | | | TC_09 | Verify no store is displayed when the selected location falls in an unavailable zone | Delivery location inside Sylhet East (#103), which has no delivery charge rule | No store is listed and an appropriate empty state is displayed. | ☐ | | | | | TC_10 | Verify the zone display name is shown to the customer instead of the business zone name | Business Zone Name: 'Dhaka North', Display Name: 'Dhaka City Delivery' | The configured display name is shown to the customer. | ☐ | | | | | TC_11 | Verify the zone display name is shown in the customer's selected language | Change the website language from English to Arabic | The zone display name is displayed in the selected language, falling back to the default value when no translation exists. | ☐ | | | | | TC_12 | Verify a newly created and fully configured zone becomes available to the customer without an app update | Create zone 'Khulna South' with Food module + delivery charge rule + ETA fully configured | The new zone becomes available to the customer after a refresh, without any browser cache clear. | ☐ | | | | | TC_13 | Verify content is refreshed correctly when the customer changes the delivery location to another zone | Change the delivery location from Dhaka North (#101) to Chattogram Central (#102) | The store list, modules and offers are reloaded according to Zone B. | ☐ | | | | | TC_14 | Verify the customer cannot place an order for an address outside the active zone | Add a delivery address in 'Cox's Bazar' (outside any active zone) | The order placement is restricted with a proper out-of-zone message. | ☐ | | | | ### Zone Setup → Module Visibility as per Connected Modules | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_15 | Verify only the connected modules of the selected zone are displayed to the customer | Dhaka North (#101) connected with Food and Pharmacy only | Only the Food and Pharmacy modules are displayed in the module selection. | ☐ | | | | | TC_16 | Verify a module not connected to the zone is not displayed to the customer | Grocery module not connected to Dhaka North (#101) | The Grocery module is not displayed for that zone. | ☐ | | | | | TC_17 | Verify all four modules are displayed when all are connected to the zone | Dhaka North (#101) connected with Food, Grocery, Pharmacy and Shop | All four modules are displayed in the module selection. | ☐ | | | | | TC_18 | Verify a newly connected module appears for the customer after the admin connects it | Connect the Shop module to Dhaka North (#101) from the admin panel | The Shop module becomes available for that zone on the customer end. | ☐ | | | | | TC_19 | Verify a disconnected module disappears for the customer after the admin disconnects it | Disconnect the Food module from Dhaka North (#101) | The Food module is no longer displayed for that zone on the customer end. | ☐ | | | | | TC_20 | Verify the stores of a disconnected module are not displayed to the customer | Disconnect the Food module from Dhaka North (#101), which has the 'Spice Hut' store active | The stores of that module are not displayed for that zone. | ☐ | | | | | TC_21 | Verify the module list is different for two zones having different connected modules | Dhaka North (#101): Food only; Chattogram Central (#102): Food + Shop | Each zone displays only its own connected modules when selected. | ☐ | | | | | TC_22 | Verify an appropriate empty state is displayed when the zone has no connected module | Sylhet East (#103) without any connected module | An appropriate empty state is displayed instead of a blank or broken page. | ☐ | | | | | TC_23 | Verify the search result does not return stores of a module not connected to the zone | Search 'Fresh Mart' (a Grocery store) in Dhaka North (#101), where Grocery is disconnected | No result of the disconnected module is returned. | ☐ | | | | | TC_24 | Verify a deep link to a disconnected module's store is handled properly | Open a deep link to 'Fresh Mart' while browsing Dhaka North (#101), where Grocery is not connected | A proper unavailable message is displayed instead of loading the store. | ☐ | | | | ### Zone Setup → Payment Method Availability | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_25 | Verify only the payment methods enabled for the zone are displayed at checkout | Dhaka North (#101) configured with Cash on Delivery and Digital Payment only | Only Cash on Delivery and Digital Payment are displayed at checkout. | ☐ | | | | | TC_26 | Verify a payment method is not displayed at checkout when it is not enabled for the zone | Dhaka North (#101) configured without: Cash on Delivery / without Digital Payment / without Offline Payment (test each case) | In each case the payment method that is not enabled for the zone is not displayed at checkout. | ☐ | | | | | TC_27 | Verify only the single enabled payment method is displayed at checkout | Dhaka North (#101) configured with: Cash on Delivery only / Digital Payment only / Offline Payment only (test each case) | In each case only the single enabled payment method is displayed at checkout and it is selected by default. | ☐ | | | | | TC_28 | Verify all three payment methods are displayed when all are enabled for the zone | Dhaka North (#101) configured with Cash on Delivery, Digital Payment and Offline Payment | Cash on Delivery, Digital Payment and Offline Payment are all displayed at checkout. | ☐ | | | | | TC_29 | Verify the payment method list updates after the admin changes the zone configuration | Remove Digital Payment from Dhaka North (#101)'s configuration | The Digital Payment option is no longer displayed at checkout after a refresh. | ☐ | | | | | TC_30 | Verify two zones with different payment configurations show different options at checkout | Dhaka North (#101): COD only; Chattogram Central (#102): COD + Digital | Each zone shows only its own configured payment options at checkout. | ☐ | | | | | TC_31 | Verify an order can be placed successfully with an enabled payment method | Place a $25 Food order in Dhaka North (#101) with Cash on Delivery | The order is placed successfully. | ☐ | | | | | TC_32 | Verify the order cannot be placed with a payment method that is disabled for the zone | Order API request using Offline Payment for Dhaka North (#101), which has Offline Payment disabled | The request is rejected by the server with a proper validation message. | ☐ | | | | | TC_33 | Verify the wallet payment behaviour follows the zone's digital payment configuration | Dhaka North (#101) without Digital Payment enabled | The wallet payment option behaves as per the defined business rule for that zone. | ☐ | | | | | TC_34 | Verify an appropriate message is displayed when no payment method is available for the zone | Dhaka North (#101) with no payment method selected in Connect Module (misconfigured) | A proper message is displayed at checkout instead of an empty payment section. | ☐ | | | | ### Zone Setup → Max COD Order Amount Enforcement | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_35 | Verify a COD order below the configured max amount can be placed successfully | Food module max COD: 500, order total: 400 | The COD order is placed successfully. | ☐ | | | | | TC_36 | Verify a COD order equal to the configured max amount is handled as per the business rule | Food module max COD: 500, order total: 500 | The order is allowed or restricted consistently as per the defined boundary rule. | ☐ | | | | | TC_37 | Verify a COD order above the configured max amount is restricted | Food module max COD: 500, order total: 600 | The COD payment option is disabled or an error message is displayed and the order cannot be placed with COD. | ☐ | | | | | TC_38 | Verify the correct restriction message is displayed when the COD limit is exceeded | Order total above the configured COD limit | A clear message is displayed informing the customer of the maximum COD order amount for that module. | ☐ | | | | | TC_39 | Verify the customer can switch to another payment method when the COD limit is exceeded | Order total above the COD limit with Digital Payment enabled | The customer can complete the order using Digital Payment successfully. | ☐ | | | | | TC_40 | Verify the module-wise max COD amount is applied independently | Food max COD: 500, Pharmacy max COD: 300 | The Food order is validated against 500 and the Pharmacy order against 300. | ☐ | | | | | TC_41 | Verify the max COD amount of one zone is not applied to another zone | Zone A Food max COD: 500, Zone B Food max COD: 1000 | Each zone applies only its own configured max COD amount. | ☐ | | | | | TC_42 | Verify no COD limit is applied when the Max COD Order Amount toggle is turned off | Max COD Order Amount toggle turned OFF for Dhaka North (#101) | A COD order of any amount can be placed successfully. | ☐ | | | | | TC_43 | Verify the COD limit is evaluated on the correct order total as per the business rule | Order with items, delivery charge, tax, tips and a coupon discount | The COD limit is evaluated consistently on the defined amount and the behaviour matches the specification. | ☐ | | | | | TC_44 | Verify the COD limit is applied correctly when the order amount changes in the cart | Increase the cart amount above the COD limit after selecting COD | The COD option is disabled or a proper message is displayed before the order is placed. | ☐ | | | | | TC_45 | Verify the COD limit is applied correctly for a scheduled order | Place a scheduled COD order above the limit | The COD payment is restricted for the scheduled order as well. | ☐ | | | | | TC_46 | Verify the updated max COD amount takes effect immediately for new orders | Change the max COD amount from 500 to 1000 in the admin panel | New orders are validated against the updated limit of 1000. | ☐ | | | | | TC_47 | Verify an already placed COD order is not affected when the max COD amount is changed | Reduce the max COD amount after an order is placed | The already placed order remains unaffected and is processed normally. | ☐ | | | | | TC_48 | Verify the COD limit is applied correctly for an order containing items from a single store only | Place a COD order above the limit from one store | The COD restriction is applied correctly. | ☐ | | | | | TC_49 | Verify the COD limit is not bypassed by editing the request payload | Send an order API request with COD above the configured limit | The server rejects the request with a proper validation error. | ☐ | | | | | TC_50 | Verify the max COD restriction message is displayed in the customer's selected language | Change the website language and exceed the COD limit | The restriction message is displayed in the selected language. | ☐ | | | | ### Zone Setup → ETA & Delivery Rule Dependency | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_51 | Verify the home page shows an empty state when the ETA is not configured for the zone | Dhaka North (#101) without an ETA configuration | An empty/service unavailable state is displayed instead of store content. | ☐ | | | | | TC_52 | Verify the home page shows an empty state when the delivery charge rule is not configured | Dhaka North (#101) without a delivery charge rule | An empty/service unavailable state is displayed instead of store content. | ☐ | | | | | TC_53 | Verify the home page shows an empty state when the ETA configuration is turned off | ETA setup status turned OFF for Dhaka North (#101) | An empty/service unavailable state is displayed. | ☐ | | | | | TC_54 | Verify the home page shows an empty state when the delivery rule status is turned off | Delivery charge rule status turned OFF for Dhaka North (#101) | An empty/service unavailable state is displayed. | ☐ | | | | | TC_55 | Verify the content loads normally once the ETA and delivery rule are configured and enabled | Configure and enable both the ETA and delivery charge rule for Dhaka North (#101) | The store list and module content load normally for that zone. | ☐ | | | | | TC_56 | Verify the delivery time shown on the store list uses the configured ETA of the zone | Dhaka North (#101) with ETA configured as 30-40 mins | The estimated delivery time displayed for the stores matches the configured ETA. | ☐ | | | | | TC_57 | Verify the delivery charge shown at checkout uses the configured delivery charge rule of the zone | Dhaka North (#101) with a Distance Wise delivery charge rule configured | The delivery charge calculated at checkout matches the configured rule. | ☐ | | | | | TC_58 | Verify the empty state is not a blank white page or a crash | Open the website with delivery location set inside Sylhet East (#103), which is unconfigured | A proper empty state UI with an icon and message is displayed and the website does not crash. | ☐ | | | | | TC_59 | Verify the customer can change the location from the empty state page | Empty state displayed for Sylhet East (#103), which is unconfigured | The customer can navigate to change the delivery location from the empty state page. | ☐ | | | | | TC_60 | Verify the previously placed orders remain visible when the zone becomes unavailable | Place 2 orders in Dhaka North (#101), then deactivate the zone from the admin panel | The order history and running order details remain accessible to the customer. | ☐ | | | | ### Zone Setup → Web Specific Behaviour | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_61 | Verify the zone-based content loads correctly after a browser page refresh | Refresh the browser page while browsing Dhaka North (#101) | The selected zone content is retained and reloaded correctly. | ☐ | | | | | TC_62 | Verify the selected zone is retained across browser tabs of the same session | Open the site in a new tab of the same browser | The previously selected zone and location are retained. | ☐ | | | | | TC_63 | Verify the zone content updates correctly when the browser back and forward buttons are used | Navigate between modules and use browser back/forward | The correct zone-based content is displayed without any error. | ☐ | | | | | TC_64 | Verify the unavailable zone empty state is displayed correctly on a mobile browser view | Open the site in a responsive mobile view (375px) for Sylhet East (#103), which is unconfigured | The empty state is displayed correctly without any layout break. | ☐ | | | | | TC_65 | Verify the zone-based content is displayed correctly on all supported browsers | Open the site on Chrome, Firefox, Edge and Safari | The zone-based module, payment and COD behaviour is identical on all supported browsers. | ☐ | | | | | TC_66 | Verify no zone or configuration data is exposed in the browser console or network response | Inspect the network responses on the storefront | No sensitive zone configuration data beyond what is required for the storefront is exposed. | ☐ | | | | ## 2. Delivery Management ### Area/Zip Code Selection | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_67 | Verify the Area/ZIP Code field on the web checkout and its dependency on the pricing method | 1. Open checkout on the React web with Home Delivery selected
2. Check the 'Area/ZIP Code *' field in the Delivery Address section for an Area Wise zone and a Zip Code Wise zone
3. Check a Distance Wise zone and a Fixed Amount zone
4. Open the dropdown and verify the listed values against the admin setup
5. Switch to Take Away and recheck | The field is shown only for Area Wise and Zip Code Wise rules with the active areas or zip codes of the customer's zone and hidden for the other methods; Take Away shows no delivery fee and no area selection. | ☑ | | | Guards restored. Field renders only when `coverage-list` returns type area_wise/zip_code_wise with options; hidden for `type: null` (distance-wise / fixed) and for take_away / dine_in. | TC_68 | Verify fee update, mandatory validation and address change on the web checkout | 1. Select different areas/zip codes and observe the Delivery Fee in the Billing panel
2. Try to Confirm Order without selecting the Area/ZIP Code
3. Change the delivery address / current location and reopen the dropdown
4. Select an unconfigured or disabled area
5. Repeat the flow as a guest user and as a logged in user | The Delivery Fee updates instantly on every selection and matches the configured charge; Confirm Order is blocked with a clear message when no selection is made; changing the address reloads the correct list and resets the selection; unconfigured or disabled areas follow the defined fallback; guest and logged in flows behave identically. | ☑ | | | Re-verified. Two bugs fixed since last check: (a) `summaryParams` was gated on `required`, silently dropping the selection so the fee never moved; (b) `keepPreviousData` kept serving the previous fee when a re-quote failed, so a 403 looked like 'no refetch'. Query key now provably changes per selection (none→zip1→zip2). Confirm-order gate still enforced via `required`. ### Delivery Charge Calculation | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_69 | Verify Area Wise, Zip Code Wise, Distance Wise and Fixed Amount fees on the web | 1. Configure one zone for each pricing method
2. Build the same cart and order under each zone
3. Note the Delivery Fee in the Billing panel and after order confirmation
4. Verify distance wise against per km rate, minimum, maximum and the vehicle category extra charge
5. Compare every fee with the customer app and the admin order details | The correct charge is applied for each pricing method with the minimum, maximum and extra charge honoured; the web fee matches the customer app and the admin panel exactly for the same cart, address and module. | ☐ | | | Key mapping now tolerates area/zip type spellings (`coverageIdKey`). Still needs the QA env: dev zone 1 is zip_code_wise only, zones 2–3 have no rule. ### Parcel → Parcel Information | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_70 | Verify the Parcel Information modal UI and options on the web | 1. Open the Parcel module and start a parcel order
2. Check the modal title, helper text and the (x) icon
3. Check the Parcel Type options (Gift, Documents, Fragile, Electronics, Packages)
4. Check the Item Weight options against the admin weight ranges
5. Check the Item Dimension radio list with measurements (Small 100 x 50 x 80 in, Medium 200 x 100 x 160 in, Large 300 x 150 x 200 in, Extra Large 400 x 200 x 250 in)
6. Check the Cancel and Confirm Information buttons | The modal renders as per the design; weight and dimension options exactly match the admin configuration with correct values and units; changes made in admin appear after a refresh; only one dimension can be selected at a time. | ☐ | | | | | TC_71 | Verify selecting, confirming, editing and cancelling parcel information on the web | 1. Select a parcel type, item weight and item dimension and click Confirm Information
2. Check the parcel card summary (e.g. 'Parcel Type - Gift / Small, Light (2-4Kg)')
3. Click the pencil icon, change the selection and confirm again
4. Observe the delivery fee after each change
5. Click Cancel and the (x) icon
6. Try to confirm without selecting weight or dimension | The confirmed values are summarised on the parcel card and can be edited repeatedly; the fee recalculates after every change; Cancel and (x) discard the change; weight and dimension are mandatory with clear validation messages. | ☐ | | | | ### Parcel → Delivery Charge | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_72 | Verify the parcel fee composition and toggle behaviour on the web | 1. Configure base, weight and dimension charges with both toggles ON
2. Create parcels with different weight and dimension combinations and check the Billing panel
3. Verify base + weight + dimension against the configuration
4. Select a weight above the maximum configured range
5. Turn the Weight toggle OFF, then the Dimension toggle OFF, and repeat
6. Compare with the customer app for the same parcel | The fee equals base plus the applicable weight and dimension charges and the breakdown itemises them; a weight above the maximum uses the last configured row; disabling a toggle removes that component from the fee; the web and the app produce identical values for the same parcel. | ☐ | | | | ### Parcel → Checkout | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_73 | Verify the parcel checkout page with sender/receiver information and validation | 1. Fill Sender Details and Receiver Details with pickup and receiver locations and click Proceed To Checkout
2. Verify the Delivery Information summary against the entered data
3. Check 'Create Account With Sender Information' as a guest
4. Select a Delivery Instruction and Deliveryman Tips (preset, Custom, Not Now, Save It For Later)
5. Submit with mandatory fields blank and with an invalid email/phone
6. Set a receiver location outside coverage | All entered information is carried into the checkout summary; guest account creation works as designed; instructions and tips are applied and shown in the billing; mandatory and format validation blocks submission with clear messages; an out-of-coverage receiver location is blocked before payment. | ☐ | | | Area/ZIP is asked on the parcel checkout. 'Receiver location outside coverage' is a zone check, separate from the area/zip list — not verified. | TC_74 | Verify the Who Will Pay selection and the billing panel on the parcel checkout | 1. Select Who Will Pay = Sender, then Receiver, and observe the payable amount
2. Check the Billing panel: parcel card with type and weight, Item Price, Addons, Delivery Fee, Discount, Coupon, Pro Discount, Subtotal
3. Add a payment method and Confirm Order for each payer option
4. Check the confirmed order and the admin order details
5. Verify the subtotal against each component | The payer selection assigns the delivery charge and total payable to the correct party and the billing panel reflects it immediately; the parcel card shows the selected type and weight; the subtotal equals the sum of components minus discounts; the confirmed order and admin record match the checkout exactly. | ☐ | | | | ### Rule Change Handling | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_75 | Verify web behaviour when the delivery rule is missing, disabled or updated | 1. Open checkout in a zone/module with no delivery rule
2. Keep the checkout open while the admin disables or edits the rule, then navigate and refresh
3. Open an order placed before the rule change and one placed after
4. Open an order placed while the weight/dimension toggles were ON after they are turned OFF
5. Use the browser back button after a fee change | A missing rule follows the defined fallback with a clear message and no order proceeds with an undefined fee; the web reflects the disabled or updated rule after navigation or refresh with no stale fee; earlier orders keep their original fee and itemised charges; back navigation never restores an outdated fee into a new order. | ☐ | | | | ### Localisation & UI | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_76 | Verify localisation, responsiveness and formatting of delivery information on the web | 1. Switch the language to EN, BN, ES and AR
2. Check the Area/ZIP Code label, delivery fee labels, billing panel and parcel modal text
3. Check desktop, tablet and mobile breakpoints
4. Check the currency symbol and decimal formatting on every component
5. Check the printed/downloaded invoice
6. Check RTL alignment in Arabic | All labels and admin created names are translated with a proper fallback; the billing panel and parcel modal do not break or overflow at any breakpoint; currency and decimal formatting match the admin panel; the invoice shows the same delivery fee breakdown; RTL layout is correct. | ⚠ | | | Labels go through `t()` but only `en.js` has the 6 new keys — ar/bn/es fall back to English. Needs translations before an RTL/localisation pass. ### Cross Platform Consistency | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_77 | Verify the delivery fee is identical across web, app and admin for the same order | 1. Build the same cart with the same address on the customer app and the React web
2. Compare the delivery fee at checkout on both
3. Place the order from the web and open it in the admin panel and the store panel
4. Repeat for a parcel order with weight and dimension charges
5. Repeat for each pricing method | The delivery fee and its breakdown are identical on the customer app, the web, the admin panel and the store panel for the same cart, address, module and parcel configuration, with no rounding or currency discrepancy. | ☐ | | | Web now quotes from `checkout-summary`, the same source the app uses, so parity is expected. Needs the QA env to confirm against app + admin. ### Express / Delay Delivery | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_78 | Verify the Express and Slightly Delay options on the web checkout | 1. Admin configures the Additional Delivery Charge for the zone and module
2. Open the web checkout and check the delivery speed options with their charge and time impact
3. Select Standard, Express and Slightly Delay in turn and observe the Delivery Fee and ETA in the Billing panel
4. Confirm an order with each option
5. Compare every value with the customer app for the same cart and address
6. Check a zone or module with no setup | All configured options render correctly on the web with the same charge and ETA impact as the app; the Billing panel updates instantly on each selection; the confirmed order records the selected option; the web, app and admin panel show identical values; only standard delivery is offered where no setup exists. | ☐ | | | | | TC_79 | Verify web express/delay behaviour with parcel orders, coupons and page navigation | 1. Place an Express parcel order carrying weight and dimension charges and check the breakdown
2. Apply and remove a coupon on an Express order
3. Select Express, navigate back to the cart and return to checkout
4. Keep the checkout open while the admin edits or removes the additional charge setup, then refresh
5. Open an order placed before the change | The express extra charge or delay reduction is itemised on top of the base, weight and dimension charges; coupons apply without double counting; navigating away and back retains or safely resets the selection with a recalculated fee; after refresh the checkout reflects the updated setup and no stale option or fee is used; earlier orders keep their recorded charge and ETA. | ☐ | | | | ### Pro Customer → Partial Delivery Charge | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_80 | Verify the pro customer partial delivery charge on an Area Wise delivery rule | 1. Admin configures an Area Wise rule (Mirpur = 10, Gulshan = 20) and enables the pro/subscription partial delivery charge benefit
2. Login as a non-pro customer, select Mirpur at checkout and note the delivery fee
3. Login as a pro customer with the same cart and address and note the delivery fee and the Pro Discount line
4. Change the area to Gulshan and observe the recalculation
5. Verify the discounted amount against the configured pro benefit (percentage or fixed partial share)
6. Confirm the order and compare the billing panel summary with the placed order | The pro customer is charged only the partial delivery fee while the non-pro customer pays the full configured area charge; the discounted portion is shown on the Pro Discount line and the payable delivery fee equals the area charge minus the pro share, calculated exactly as configured; changing the area recalculates both the base charge and the pro share instantly; the confirmed order carries the same values. | ☐ | | | Blocked: no area_wise zone exists on dev, so `area_id` has never been exercised end to end. Verified live that `area_id` is ignored on a zip_code_wise zone. | TC_81 | Verify the pro customer partial delivery charge on a Zip Code Wise delivery rule | 1. Admin configures a Zip Code Wise rule with different charges per zip code
2. Place the same cart as a non-pro and as a pro customer under the same zip code
3. Compare the delivery fee, the Pro Discount line and the subtotal
4. Change the zip code selection and observe the recalculation
5. Select a zip code with the highest and the lowest configured charge
6. Confirm the order and check the invoice | The pro partial delivery charge is applied on the charge configured for the selected zip code; the discount scales correctly with the zip code charge for both the highest and lowest values; changing the zip code recalculates the pro share immediately; the invoice and the placed order show the same breakdown as {screen}. | ☑ | | | Unchanged — server-side, verified live (zip 1 base 40 → saving 4; zip 2 base 50 → saving 5). | TC_82 | Verify the pro customer partial delivery charge on a Distance Wise delivery rule | 1. Admin configures Per Km = 5, Minimum = 10, Maximum = 100 and the pro benefit
2. Place a pro order at 1 km where the calculated value falls below the minimum
3. Place a pro order at 8 km within the normal range
4. Place a pro order at 40 km where the calculated value exceeds the maximum
5. Place the same three orders as a non-pro customer and compare
6. Check whether the pro share is calculated on the raw distance value or on the clamped value | The pro partial discount is applied on the final distance based charge after the minimum and maximum limits are applied, exactly as per the defined rule, and never on the unclamped raw value; the pro customer pays less than the non-pro customer in all three cases; the payable fee is never negative and never below any configured floor. | ☐ | | | | | TC_83 | Verify the pro customer partial delivery charge on a Fixed Amount delivery rule | 1. Admin configures a Fixed Amount rule (Delivery Charge = 5) and the pro benefit
2. Place pro orders from a near store and a far store in that zone
3. Place the same orders as a non-pro customer and compare the fees
4. Place a small cart order and a large cart order as a pro customer
5. Place orders from two modules in the same zone | The same partial delivery charge is applied to every pro order in that zone regardless of distance or cart value; the pro customer consistently pays the fixed charge minus the configured pro share while the non-pro pays the full fixed amount; each module follows the rule mapped to that zone and module combination. | ☐ | | | | | TC_84 | Verify the interaction between the pro partial delivery charge and the configured Minimum Delivery Charge | 1. Admin sets a Minimum Delivery Charge of 10 in the rule
2. Place a pro order where the base charge equals the minimum delivery charge
3. Place a pro order where the pro discount would take the payable fee below the minimum delivery charge
4. Place a pro order where the pro discount is 100% of the delivery fee
5. Compare the payable fee with the configured minimum in each case
6. Repeat for Area Wise, Zip Code Wise, Distance Wise and Fixed Amount rules | The minimum delivery charge is respected exactly as per the defined rule in every pricing method — either the payable fee is floored at the minimum or the pro discount is allowed to reduce it further, but the behaviour is identical across all four methods and is the same on both the customer app and the web; the payable delivery fee never becomes negative and the order can always be completed. | ☐ | | | Min-charge vs pro-discount interaction is entirely server-side now (client no longer clamps). Needs a zone with a minimum configured. | TC_85 | Verify the Pro Discount line and the subtotal calculation in the billing summary | 1. Open the billing summary as a pro customer and check the lines: Item Price, Addons, Delivery Fee, Discount, Coupon, Pro Discount, Subtotal
2. Verify the Delivery Fee line against the configured base charge
3. Verify the Pro Discount amount against the configured pro benefit
4. Recalculate the Subtotal manually from all components
5. Check the same summary for a non-pro customer
6. Check the currency symbol and decimal formatting on the Pro Discount line | The Delivery Fee line shows the full base charge and the pro share is shown separately on the Pro Discount line (or the fee is shown already reduced, consistently with the defined display rule) with no double deduction; the subtotal equals item price plus addons plus delivery fee minus all discounts; the Pro Discount line is hidden or zero for a non-pro customer; currency and decimal formatting are correct. | ☐ | | | | | TC_86 | Verify the pro partial delivery charge on parcel orders carrying weight and dimension charges | 1. Admin enables the weight and dimension rules with charges and the pro benefit
2. Place a pro parcel order with a configured weight range and dimension
3. Verify whether the pro discount applies to the base charge only or to the total including the weight and dimension charges
4. Place the same parcel as a non-pro customer and compare
5. Turn the weight toggle off and repeat, then the dimension toggle off
6. Check the breakdown on the billing panel and on the placed order | The pro partial discount is applied exactly as per the defined rule on the base charge or on the total delivery fee, and the same rule is applied consistently every time; the weight and dimension components remain itemised in the breakdown; disabling a toggle removes that component before the pro share is calculated; the pro customer always pays less than the non-pro for the identical parcel. | ☐ | | | | | TC_87 | Verify the pro partial delivery charge combined with coupons, discounts and campaigns | 1. Apply a normal coupon on a pro order and check the delivery fee and the Pro Discount line
2. Apply a free delivery coupon on a pro order
3. Apply a delivery discount campaign together with the pro benefit
4. Remove each coupon and observe the recalculation
5. Verify that the delivery fee is not discounted twice
6. Compare the final payable amount with a manual calculation | The pro share and any coupon or campaign discount are applied in the defined order without discounting the delivery fee twice; a free delivery coupon reduces the fee to zero and the pro discount is not additionally deducted from the total; removing a coupon restores the correct pro-discounted fee; the final payable amount matches the manual calculation exactly. | ☐ | | | | | TC_88 | Verify the pro partial delivery charge combined with Express and Slightly Delay Delivery | 1. Admin configures Express (extra charge) and Slightly Delay (reduce charge) for the zone and module
2. Place a pro order with Express Delivery and check the fee and the Pro Discount line
3. Place a pro order with Slightly Delay Delivery
4. Place the same two orders as a non-pro customer and compare
5. Verify whether the pro share is calculated before or after the express/delay adjustment
6. Check that the payable fee stays at or above the configured minimum | The express extra charge and the delay reduction are applied together with the pro share in the defined sequence and the result is consistent every time; the pro customer pays less than the non-pro for the same delivery speed; the payable delivery fee never becomes negative and respects the minimum delivery charge rule. | ☐ | | | | | TC_89 | Verify pro subscription state changes and benefit limits during the ordering flow | 1. Place an order as a customer whose pro subscription is active and note the fee
2. Let the subscription expire (or cancel it) and place the same order again
3. Subscribe to pro while the billing panel is open, then refresh and observe the fee
4. Place orders until the pro benefit usage limit or maximum discount cap is reached
5. Place one more order after the cap is exhausted
6. Place an order with a pro plan that does not include the delivery benefit | The pro partial delivery charge is applied only while the subscription is active and only for plans that include the delivery benefit; after expiry, cancellation or exhaustion of the usage limit or discount cap, the full delivery charge is applied with a clear indication instead of a silent wrong fee; subscribing mid-session applies the benefit after a refresh without re-login. | ☐ | | | | | TC_90 | Verify the pro discounted delivery charge is retained on the placed order, history and invoice | 1. Place pro orders under each pricing method and note the fee and the Pro Discount amount
2. Open the placed order details and the order history
3. Download or view the invoice
4. Admin changes the delivery rule and the pro benefit configuration
5. Reopen the same orders on the billing panel
6. Compare with the admin panel and the store panel for the same orders | The delivery fee and the pro discount recorded at order time are retained everywhere and never recalculated after a configuration change; the order details, history, invoice, admin panel and store panel all show the same values; a cancelled or refunded pro order handles the discounted delivery charge as per the defined refund rule. | ☐ | | | Placed orders read their recorded fee from the order payload, not from a re-quote — expected to hold. Not verified end to end. | TC_91 | Verify the pro partial delivery charge where no rule, no benefit or an unconfigured area applies | 1. Place a pro order in a zone/module that has no delivery rule
2. Place a pro order for an area or zip code with no charge configured
3. Place a pro order in a zone where the rule is disabled
4. Place a pro order where the base delivery charge is zero (free delivery store or campaign)
5. Check the Pro Discount line in each case | A missing rule or unconfigured area follows the defined fallback with a clear message and no order proceeds with an undefined fee for a pro customer; when the base delivery charge is zero, no pro discount is calculated and the Pro Discount line shows zero or is hidden rather than a negative value; no crash or blank fee occurs in any case. | ☑ | | | Still holds, and strengthened: with `keepPreviousData` removed a failed re-quote no longer shows a stale fee, so an unconfigured/disabled area surfaces instead of silently billing the previous amount. `isQuoteUnavailable` blocks placement. ### Vendor Self Delivery | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_92 | Verify the delivery fee shown for a self delivery store | 1. Order from a store with Self Delivery OFF in a zone with an active rule and note the fee
2. Order from a store with Self Delivery ON in the same zone and note the fee
3. Compare both against the admin rule charge and the vendor configured charge
4. Order from a self delivery store offering free delivery
5. Check the fee on the store page, the cart, checkout and the placed order
6. Add items from a self delivery store and a normal store where multi-store carts are allowed | The self delivery store charges the vendor's own fee (or nothing when free delivery is on) while the normal store charges the rule based fee; the same value is shown on the store page, cart, checkout and the placed order; a mixed cart applies the correct fee per store or is blocked as per the defined rule. | ☐ | | | | | TC_93 | Verify checkout behaviour and other delivery features for self delivery stores | 1. Open checkout for a self delivery store and check whether the Area/ZIP Code field is required
2. Check whether Express and Slightly Delay Delivery options are offered
3. Place a pro customer order from a self delivery store and check the Pro Discount line
4. Apply a free delivery coupon on a self delivery order
5. Change the delivery address and observe the fee
6. Order from a self delivery store in a zone that has no delivery rule at all | Fields and options that belong to the admin rule (area/zip selection, express and delay options) are hidden or handled exactly as per the defined self delivery behaviour and never block the order; the pro discount and coupons apply to the self delivery fee per the defined rule without a negative total; a self delivery store can be ordered from even where no delivery rule exists. | ☑ | | | Guards restored. Hidden when `self_delivery_system === 1`, so the admin-rule field never blocks a self-delivery order. Fed from storeData in the mart and prescription checkouts. ## 3. Additional Delivery Charge ### Checkout → Delivery Options | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_94 | Verify the delivery options section is displayed at checkout in the react web | Home Delivery checkout for 1) Food 2) Grocery 3) Pharmacy 4) Shop | The Delivery Options section shows Standard Delivery, Express Delivery and Slightly Delay Delivery with their own time range and delivery charge for each module. | ☐ | | | | | TC_95 | Verify the Standard Delivery card data | Store time range 30 - 50 Min \| Base delivery charge $50 | Standard Delivery shows the store time range and the base delivery charge without any addition or deduction. | ☐ | | | | | TC_96 | Verify the Express Delivery card data | Add Extra Charge $20 \| Reduce Delivery Time 20 Min \| Base charge $50 | Express Delivery shows the reduced time range, the '+ $20' extra charge indication and the increased total delivery charge ($70). | ☐ | | | | | TC_97 | Verify the Slightly Delay Delivery card data | Reduce Charge $10 \| Add Extra Delivery Time 20 Min \| Base charge $50 | Slightly Delay Delivery shows the extended time range, the '- $10' reduced charge indication and the decreased total delivery charge ($40). | ☐ | | | | | TC_98 | Verify only one delivery type can be selected at a time and the billing updates instantly | Select 1) Express 2) Slightly Delay 3) Standard one after another | Only one option stays selected, Standard Delivery is selected by default and the delivery charge & total amount in the billing section update instantly with each selection. | ☐ | | | | ### Express Delivery Time Range Calculation | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_99 | Verify the express time range when the admin minimum time is greater than the store minimum time (Case 1) | Admin Minimum Delivery Time = 40 \| Store delivery time = 30 - 50 | The express delivery time range is displayed as 40 - 50. | ☐ | | | | | TC_100 | Verify the express time range when the admin minimum time is less than the store minimum time (Case 2) | Admin Minimum Delivery Time = 20 \| Store delivery time = 30 - 50 | The express delivery time range is displayed as 20 - 50. | ☐ | | | | | TC_101 | Verify the express time range when the admin minimum time is greater than the store maximum time (Case 3) | Admin Minimum Delivery Time = 60 \| Store delivery time = 30 - 50 | The express delivery time range is displayed as 30 - 60. | ☐ | | | | | TC_102 | Verify the range display rule of the calculated minimum and maximum time | 1) Calculated Max > Min 2) Calculated Max = Min 3) Calculated Max < Min | A time range (min - max) is displayed when the max is greater than the min and 'Up to {min}' is displayed when the max is equal to or less than the min. | ☐ | | | | | TC_103 | Verify the time unit conversion in the displayed range | Setup time in 1) Min 2) Hour with the store time range in min/hour (e.g. 24 hr 40 min) | The delivery time is displayed with the correct unit and the min/hour conversion is accurate in every combination. | ☐ | | | | | TC_104 | Verify the slightly delay delivery time range | Add Extra Delivery Time = 20 Min \| Store delivery time = 30 - 50 Min | The slightly delay time range is extended by the configured extra time and is always greater than the standard delivery time range. | ☐ | | | | ### Delivery Charge Calculation | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_105 | Verify the delivery charge never goes below the minimum delivery charge | Base charge $12 \| Delivery Rule Minimum Delivery Charge $10 \| Reduce Charge $5 | The slightly delay delivery charge is limited to $10 and never goes below the minimum delivery charge of the delivery rule. | ☐ | | | | | TC_106 | Verify the additional charge is calculated after the base delivery charge of every rule type | Delivery rule 1) Fixed 2) Area wise 3) Zip code wise 4) Distance wise 5) Parcel with weight & dimension | The base delivery charge is calculated first from the applicable rule and then the express/slightly delay charge is added or deducted from that final charge. | ⚠ | | | **Open risk:** the client still adds `cappedDeliveryOptionSurcharge` on top of the server-quoted fee while also sending `delivery_type` to `checkout-summary`. Double-counts if the server applies the express/delay charge. Not reproducible on dev (`additional_delivery_option_status: false`). | TC_107 | Verify the order breakdown of the selected delivery type | Place an 1) Express 2) Slightly Delay order and check the checkout billing and the order details page | The extra/reduced charge is shown as a separate line at the end of the delivery charge breakdown on both the checkout page and the order details page. | ☐ | | | | | TC_108 | Verify the delivery charge with a discount, coupon or tips applied together | Apply a normal discount coupon and a deliveryman tip with an express order | The delivery type charge is calculated correctly along with the coupon discount and tips and the payable total amount matches the breakdown. | ☐ | | | | ### Section Visibility & Edge Cases | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_109 | Verify the delivery options section is hidden for Take Away and Dine In | Switch the delivery option to 1) Take Away 2) Dine In | The Standard/Express/Slightly Delay delivery section is hidden and no additional delivery charge is applied to the order. | ☑ | | | Both halves met: the section returns null unless `orderType === 'delivery'`, and `deliveryOptionSurcharge` is forced to 0 for anything else, so no additional charge reaches the total. | TC_110 | Verify the section with an active free delivery setup | 1) Free Delivery for all Store 2) Specific criteria free delivery with the criteria met | The delivery type section is hidden and the delivery charge remains free for the order. | ☐ | | | Mechanism is in place (`canShowDeliverySpeedOptions = deliveryFee > minimumDeliveryCharge`, and free delivery drives the server-quoted fee to 0), but no free-delivery config exists on dev to exercise it. | TC_111 | Verify the section with a free delivery coupon | Apply a free delivery coupon and then remove it | The section is disabled with a proper warning message while the coupon is applied and becomes selectable again after the coupon is removed. | ⚠ | | | Half met. A free_delivery coupon disables the section (opacity 0.45 + pointerEvents none) and re-enables on removal, but **no warning message is rendered** — the expected result asks for one. | TC_112 | Verify the section when no active Additional Charge setup exists for the zone & module | 1) No setup created 2) Setup status inactive 3) Setup deleted | Only the Standard Delivery option is shown without any Express or Slightly Delay Delivery option and the order is placed with the base delivery charge. | ⚠ | | | Discrepancy. With `additional_delivery_option_status: false` the component returns null, hiding the whole section — but the expected result says *'Only the Standard Delivery option is shown'*. Dev zone 1 is in exactly this state. Needs a decision: render a lone Standard card, or amend the case. | TC_113 | Verify the estimated arrival time after placing the order | Place an express and a slightly delay order and open the order details | The Estimated Arrival of the order details shows the same time range that was selected at checkout. | ☐ | | | | | TC_114 | Verify the selected delivery type persists during the checkout flow | Select Express -> change the address/payment method -> come back to the checkout page -> place the order | The selected delivery type and its charge remain the same and the placed order carries the correct delivery type. | ☐ | | | | | TC_115 | Verify multi language and currency display of the delivery type section | Change the 1) Language (Default/English/Arabic - RTL) 2) Currency | The delivery type labels, time ranges and charges are translated and displayed with the correct currency symbol and position in every language including RTL. | ☐ | | | | ## 4. Free Delivery Setup ### Customer Web (React) → Free Delivery Display & Charge | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_116 | Verify free delivery display and charge on the React web for both types | 1. Browse a zone/module with the All Store type across Food, Grocery, Pharmacy and Shop
2. Open a store list, store details, cart and checkout
3. Browse a zone/module with the Specific Criteria type and a 500 minimum
4. Build a cart below, exactly at and above 500
5. Place orders on both types and open the order details and invoice | 1. The free delivery label/badge appears only for the configured modules
2. Every page shows a 0 delivery fee with the correct total
3. The normal delivery charge is shown until the minimum is met
4. The fee switches to 0 at and above 500 and back to the normal charge below it, updating live
5. The stored delivery charge is consistent across the order details, invoice and email | ☐ | | | | | TC_117 | Verify zone/module scoping and address change on the web | 1. Change the delivery address to a zone without free delivery
2. Change to a zone with free delivery on a different module
3. Order from a non-configured module of the same zone
4. Keep the cart and switch addresses back and forth
5. Open the checkout in two browser tabs and change the address in one | 1. The normal delivery charge is applied and the free delivery label disappears
2. Free delivery applies only to the matching module
3. The normal charge is applied
4. The delivery fee and total recalculate correctly every time with no stale value
5. The tab that submits the order uses the server-recalculated charge, not the stale client value | ☐ | | | | | TC_118 | Verify browser-specific behaviour, responsiveness and language on the web | 1. Refresh the checkout page with a qualifying cart
2. Use the browser back/forward buttons around the cart and checkout
3. Open the site on desktop, tablet and mobile widths
4. Switch to another language and to an RTL language
5. Check the free delivery label and bill summary on a slow connection / while the fee is loading | 1. The delivery fee and total remain correct after the refresh
2. The cart state and delivery fee stay consistent with no duplicate charge
3. The layout and the bill summary render correctly at every breakpoint
4. All strings are translated and aligned correctly in RTL
5. A proper loader or placeholder is shown; no wrong or flickering fee is displayed before the value loads | ☐ | | | | ## 5. Surge Price ### Surge Price Application on Delivery Fee | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_119 | Verify the delivery fee increases when an active surge price applies | 1. Note the normal delivery fee outside the surge window
2. Place the same cart inside an active surge window (Main Zone + Food, 50%)
3. Compare the delivery fee
4. Verify the order total | *(truncated — the paste was cut off here by the message size limit)* | ☐ | | | | > **The source paste ends mid-TC_119.** Everything after this point in the > original sheet (the rest of Surge Price, and TC_120–TC_225) is missing. > Re-send it in a follow-up and it can be appended. ## 6. ETA _From the earlier message in the same sheet._ ### Order Details → Estimated Arrival UI | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_226 | Verify the order details page opens with the delivery map and the Estimated Arrival section displayed | Logged in customer with an active order, ETA 5:30 - 6:00 PM | 1. The page loads without error with the map and both location pins
2. The 'Estimated Arrival' label and the range '5:30 - 6:00 PM' are displayed. | ☐ | | | | | TC_227 | Verify the order status line is displayed below the ETA with the status word in its defined colour | Pending, Confirmed, Processing and Out for delivery orders | The line 'Your order is Pending. Waiting for confirmation.' is displayed and each status word uses its defined colour. | ☐ | | | | | TC_228 | Verify the tracking arrow, the store and delivery details and the 'See More' expansion work correctly | Click the arrow, then click 'See More' | 1. The order tracking view opens
2. The store name and address and the customer name, phone and delivery address are displayed and the additional details expand. | ☐ | | | | | TC_229 | Verify the Estimated Arrival section is displayed for running statuses and hidden for closed ones | 1. Pending, Confirmed, Processing, Handover, Out for delivery
2. Cancelled, refunded, failed and delivered orders | 1. The section is displayed for every running status
2. It is hidden for cancelled, refunded and failed orders, and hidden or replaced with the actual delivery time for a delivered order. | ☐ | | | | ### Order Details → ETA by Order Status & Calculation | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_230 | Verify the distance based ETA reflects the Maps travel time plus the Preparation Buffer plus the Transit Buffer | Maps 20, Preparation Buffer 10, Transit Buffer 5 | The ETA start is 35 minutes from the order time. | ☐ | | | | | TC_231 | Verify the distance based ETA recalculates after processing starts by replacing the Preparation Buffer with the actual processing time | Maps 20, Transit Buffer 5, processing time 8 | The ETA updates automatically to 33 minutes when the order moves to Processing. | ☐ | | | | | TC_232 | Verify the fixed method ETA reflects the store min-max delivery time plus both buffers and ignores distance | Store 20-30, Preparation Buffer 10, Transit Buffer 5, with a near and a far address | The ETA range is 35 to 45 minutes and is identical for both addresses. | ☐ | | | | | TC_233 | Verify the fixed method ETA recalculates after processing starts by replacing the Preparation Buffer with the actual processing time | Store min 20, Transit Buffer 5, processing time 12 | The range start becomes 37 minutes. | ☐ | | | | | TC_234 | Verify the displayed range end equals the range start plus the ETA Range Gap and never falls below the Minimum Delivery Time | 1. Range start 5:30 PM, ETA Range Gap 30
2. Calculated 12, Minimum Delivery Time 30 | 1. The range end is 6:00 PM
2. The displayed ETA is at least 30 minutes. | ☐ | | | | | TC_235 | Verify the ETA is displayed for every running status and replaced with the delivery time once delivered | Pending, Confirmed, Processing, Handover, Out for delivery, then Delivered | The estimated arrival range is displayed with the matching status text throughout and the delivered time replaces it at the end. | ☐ | | | | | TC_236 | Verify the ETA updates without a manual refresh, stays stable on reopen and tracks the deliveryman location | 1. Change the status from the admin panel
2. Reopen the order details
3. Deliveryman location updated | 1. The ETA and status update automatically
2. The same ETA is displayed without fluctuation
3. The ETA updates per the defined live tracking rule. | ☐ | | | | | TC_237 | Verify the ETA changes when the delivery address is changed and when the store updates its delivery time range | 1. Change the delivery address in the cart
2. Store updates its min/max, then place a new order | The ETA is recalculated correctly in both cases. | ☐ | | | | ### Order Details → Module, Zone & Fallback | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_238 | Verify the ETA is displayed correctly for each active module order using its own configuration | Food, Grocery, Pharmacy and Shop orders | Each order shows the ETA calculated from its own module configuration. | ☐ | | | | | TC_239 | Verify the ETA applies the configuration of the order's zone, including a zone boundary address | Order in a configured zone, then an address near the zone boundary | The correct zone specific configuration is applied in both cases. | ☐ | | | | | TC_240 | Verify a default ETA is displayed when no configuration exists, the configuration is inactive, the Maps API is down or the store has no min/max | 1. No configuration for the zone and module
2. Configuration deactivated
3. Maps API down
4. Store without min/max delivery time | A documented default or fallback ETA is displayed in all four cases without any error or crash. | ☐ | | | | | TC_241 | Verify a configuration update applies to new orders only and a mid order deletion does not break the running order | Admin updates the buffers with a running order, then place a new order and delete the configuration | The new order uses the updated values, the running order retains its original ETA and continues without any ETA error. | ☐ | | | | | TC_242 | Verify the ETA display for Parcel, self pickup / takeaway and scheduled orders | Parcel order, takeaway order and scheduled order | Each is displayed per the defined rule for that order type. | ☐ | | | | ### Order Details → Localization, UI & Edge Cases | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_243 | Verify the ETA is displayed in the configured time format and timezone with correct AM/PM and midnight crossover | 12 and 24 hour formats, orders at 9:00 AM, 5:00 PM and 11:50 PM with a 30 minute ETA | The ETA is displayed in the configured format and local time, with correct AM/PM and a correct midnight crossover. | ☐ | | | | | TC_244 | Verify the ETA labels are translated on language change and render correctly in RTL | Change the language, then select Arabic | All labels are translated with no raw key and the section mirrors correctly with the time range displayed without reversed digits. | ☐ | | | | | TC_245 | Verify the Estimated Arrival section renders correctly on a small and a large browser window | Small browser window, then large browser window | The section renders without truncation, overlap or layout issues in both cases. | ☐ | | | | | TC_246 | Verify a loader is shown on a slow network and a fallback is shown when the ETA API fails or returns null | Throttled network, then a forced API failure and a null ETA response | A loader is displayed while loading and a fallback message or default ETA is shown with no crash. | ☐ | | | | | TC_247 | Verify the ETA never displays a negative value or a reversed time range | Processing time greater than the total ETA, misconfigured store delivery range | No negative value and no reversed range are displayed. | ☐ | | | | | TC_248 | Verify the ETA is retained on reopen, reloads on refresh and stays consistent across the order list and notifications | Close and reopen the order details, refresh, then compare with the order list and the status notification | The same ETA is displayed everywhere and reloads with the current value. | ☐ | | | | | TC_249 | Verify multiple running orders each display their own correct ETA | 3 running orders in different zones | Each order displays its own correctly calculated ETA. | ☐ | | | | ### Order Details → Browser Specific Checks | Sl. | Test Case | Test Data | Expected Result | Dev Check | QA Status | Actual Result | Remarks | |---|---|---|---|:-:|:-:|---|---| | TC_250 | Verify the Estimated Arrival section renders consistently across supported browsers and viewports | Chrome, Firefox, Edge, Safari, then 375x812, 768x1024 and 150% zoom | The section renders correctly and stays readable in every browser and viewport. | ☐ | | | | | TC_251 | Verify the ETA is retained after a page refresh and after back and forward navigation with no console error | Press F5, navigate away and back, then open the browser console | The same ETA is displayed with no stale value and no JavaScript error is logged. | ☐ | | | | | TC_252 | Verify another customer's order ETA cannot be viewed by changing the order id in the URL | Modified order id in the URL | Access is denied and no other customer's ETA is exposed. | ☐ | | | |