Multi-Branch Package Creation — QA Test Plan
Companion to the business hub, FE plan, and BE contract.
| Owner | QA |
| Systems | hh-server and book-bite Partner Portal |
| Status | Aligned with final business decisions |
1. Test principles
- Creation is one request and one all-or-nothing transaction.
- A multi-restaurant creation creates one shared package, not one independent package per restaurant.
- One new-package submission is auto-approved for each create, including a multi-restaurant create.
- Package edits remain in the existing approval workflow.
- Single-restaurant staff can view a shared package but cannot edit or deactivate it.
- Group staff can edit a shared package, including when they can access only some attached restaurants.
- Active and expiry behavior remains per
RestaurantPackage. - Notifications target the submitting staff member only; no per-restaurant duplicate email is expected.
2. Backend test matrix
| Area | Expected result |
|---|---|
| Legacy create | One package and one restaurant package; existing response and defaults remain compatible. |
| Group create | One package with one restaurant package per selected restaurant. |
| Selected restaurant access | An inaccessible ID returns 403 and creates no rows. |
| Single staff multi-selection | Request is rejected with 403; no package is created. |
| Empty selection | Request is rejected; no package is created. |
| Duplicate IDs | IDs are normalized according to the API contract; no duplicate restaurant package is created. |
| Atomicity | Any nested validation/persistence failure rolls back package, restaurant packages, and submissions. |
| Auto approval | One creation submission is approved; all restaurant packages publish only after the transaction succeeds. |
| Shared read | Single staff can retrieve a shared package attached to an accessible restaurant. |
| Shared edit: single staff | 403; package and submission count remain unchanged. |
| Shared edit: group staff | Existing edit submission is created; package-level change is available to all attached restaurants after approval. |
| Shared edit: partial access | Group staff can edit through an accessible branch even when another attached branch is outside their access. |
| Shared deactivate: single staff | 403; target RestaurantPackage remains unchanged. |
| Per-restaurant state | Deactivation or expiry of one restaurant package does not alter another. |
| Defaults | Existing payment, commission, pricing, and snapshot behavior remains the same; default restaurant is the reference/fallback. |
| Email behavior | Create does not send approval/pending emails; edit notifications go only to the submitting staff member. |
3. Frontend test matrix
| Area | Expected result |
|---|---|
| Group Login create | Branches field renders and supports one, several, or all accessible restaurants. |
| Single-restaurant create | Existing form and payload remain unchanged; no restaurant_ids. |
| All Branches | Resolves to the current accessible restaurant IDs at submit time. |
| Empty selection | Submit is blocked with required-selection copy. |
| Submit behavior | One request, button locked while pending, one success/failure state. |
| No partial success | UI never reports some branches succeeded because the backend transaction is atomic. |
| Shared package visibility | Single staff can open/view the package. |
| Shared package actions | Single staff cannot use Edit or Deactivate. |
| Group shared edit | Group staff can use the normal package edit form; no branch selector is shown. |
| Partial group access | Group staff can edit a shared package selected through an accessible branch. |
403 fallback | Direct API permission failures show an error and do not clear user input unexpectedly. |
| Per-restaurant deactivation | UI action targets one RestaurantPackage, not the shared package globally. |
4. Critical cases
P0
- Three accessible restaurants create one package and three restaurant packages.
- A failure during nested persistence leaves zero package, restaurant package, and submission rows.
- A single-restaurant staff member cannot create for multiple restaurants.
- A single-restaurant staff member can view but cannot edit a shared package.
- A Group staff member can edit a shared package.
- An inaccessible restaurant ID cannot be used to create or mutate a package.
P1
All Branchesselection submits the current complete list.- Non-group create request is unchanged.
- Group staff with partial access can edit through an accessible attached restaurant.
- Deactivate remains blocked for single staff and scoped per restaurant for Group staff; no partner delete route exists.
- Existing approval and notification flow remains intact.
5. Regression risks
- The create service is shared by every package creation path; run the existing AYCE and Party Pack suites.
- The package lookup scope must expand enough for shared-package viewing without exposing inaccessible branches.
- The FE must not interpret a shared package as multiple independent packages.
- A disabled FE button is not sufficient; verify the API guard directly.
- Existing payment/default snapshot behavior must not be recalculated separately per selected restaurant.
6. Definition of done
- Backend request and service specs pass.
- Book-bite component and end-to-end tests pass.
- Single-restaurant regression tests pass.
- Group create, shared view, shared edit, and permission cases are covered.
- No partial-success UI or batch-id assumptions remain.
- Manual staging smoke covers one shared package across at least two restaurants.