Lab 4 — Allocation-to-Delivery Test Charter

Time: 35 minutes
Team: groups of three

Quick start

First action: Read the feature request and R8, then copy the charter template.

Finish with: A risk-ranked charter covering every required area and your first three tests.

Step-by-step help for Session 04 — smaller steps, checkpoints and troubleshooting. Saving and asking for help.

Mac / Linux / Windows

Submission: prepare the deliverables below using the public-safe packet and review workflow. One PR per lab; private review is equally available. Never publish grades or personal information.

Complete the charter in a plain-text/Markdown editor or an approved browser document on any OS. Include Mac/Linux/Windows and browser differences in your test matrix where relevant, with separate coverage for keyboard settings and rendering. Platform coverage is not proof until tested.

See the platform guide and included local lab track.

Scenario

Feature request: “A concierge can reserve an event allocation after confirming a deposit, and the customer receives an update.” The request is intentionally incomplete.

Mission

Create a risk-based test charter that a manual tester, an automation engineer, and a product owner can all use.

Required coverage

• successful allocation and notification;
• duplicate/concurrent attempt;
• failed or delayed deposit confirmation;
• wrong user role/organization;
• consent or communication-preference boundary;
• accessible and mobile-visible confirmation;
• recovery/audit-trail behavior.

Steps

1. List the user, goal, state before/after, and non-goals.
2. Ask an AI tool for additional cases, then label which you keep, reject, or need clarified.
3. Rank the top risks by harm, likelihood, and detectability.
4. Use the charter template to specify evidence and synthetic data needs.
5. Present the three tests you would run first and why.

Deliverables and rubric

Ready for review when risks are tied to people/business outcomes, not generic “test everything” language. For each coverage area, give either a requirement-backed observable result or an explicit clarification blocker with the decision owner and a conditional test. R8 deliberately leaves deposit/refund/concurrency rules unresolved: a well-scoped question demonstrates good reasoning; an invented business rule does not. Label proposed criteria as proposals, not approved requirements. This is a design lab; no payment execution or separate learner examination is required.

Stretch

Mark each case: manual exploratory, deterministic automated, AI-assisted exploration, or human approval. Defend the boundary.

Product Studio homework — Define what quality means

Write acceptance criteria and a risk-ranked charter for your product. Include success, negative and boundary cases, the first three checks and any unresolved rules requiring instructor input.

Budget two to three hours, including evidence and review preparation; ask for coaching or scope adjustment if blocked. Record progress using the milestone template in your own product repository, not the practice packet. See the complete project roadmap, GitHub workflow and small-model guide. The practice lab above remains separate from your individual product.