Risk-based test plan for the checkout release

What you'll produce

A one-to-two-page risk-based test plan for the ShopSphere checkout-and-promo-code release — the strategy document a QA lead signs off before anyone starts testing. It nails down scope (what's in, what's out), which testing types you'll apply, the target environments/devices/browsers, the entry and exit criteria that gate the release, and a risk-prioritized list of what to test first. This is the deliverable that proves you can "shift left" (Topic 3) and turn a vague spec into a defensible plan: it shows you understand that you can't test everything (Topic 5), so you prioritize by risk and write down — before testing starts — exactly what "ready to release" means. It's the foundation every later capstone artifact (test cases, executed runs, bug reports, sign-off) builds on, and it's the single most common QA work sample a hiring manager will ask to see.

Instructions

1. Read the spec like a tester, not a reader. From the ShopSphere brief, list the four things this release actually changes: redesigned checkout, new promo-code field, guest checkout, and Apple Pay. For each, write one sentence on what could go wrong with money or order completion — that's your risk radar.
2. Define scope explicitly — both halves. Write an In scope list (the features and flows you will test) and an Out of scope list (what you're deliberately not testing, e.g., the existing product-catalog pages, account-settings, the payment processor's own internals). The out-of-scope list is what separates a real plan from a wish list; it protects your two-week timeline.
3. Map testing types to the feature (Topic 4). State which types you'll apply and where: functional (does promo-code apply correctly?), regression (did the checkout redesign break the existing cart?), smoke (does each daily build even reach the payment step?), plus the relevant non-functional types — compatibility (browsers/devices/OS), usability (the redesigned flow), and a note on security/performance if they're owned by specialists. Don't list types you won't actually run.
4. Pin down the test environment matrix. Name the staging environment (where daily builds land), and list the specific browsers, devices, and OS versions you'll cover — with a deliberate priority order, not "all of them." Tie the choice to where ShopSphere's real traffic is (mobile-heavy retail) and to the features (Apple Pay forces Safari/iOS into scope).
5. Write entry and exit criteria as checkable gates. Entry criteria = what must be true before you start testing a build (spec frozen, build deployed to staging, smoke test passes). Exit criteria = the bar a build must clear to be recommended for release (e.g., 100% of priority-1 cases pass, zero open Critical/High defects, regression suite green). These must be binary — a release manager should be able to check each one off.
6. Build the risk-prioritized "what to test first" table. For each feature area, rate Likelihood (how likely it is to fail) and Impact (how bad if it does), derive a Risk level, and assign a test priority (P1–P3). Anything touching money, order placement, or a brand-new code path is high impact — promo-code math and payment go first; cosmetic copy goes last. This table is the heart of the plan: it's why you test in the order you test.
7. Add a brief assumptions/dependencies & sign-off line. Note what you're depending on (stable staging, test promo codes seeded, sandbox Apple Pay account) and leave a line for the QA lead's sign-off. State your estimated effort against the two-week window so the plan is honest about time.
8. Keep it to one-to-two pages. A test plan no one reads is worthless. Tight scope, scannable tables, no filler.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Scope (in and out) — 1: only lists what to test, no out-of-scope · 2: clear in-scope and out-of-scope lists · 3: scope is specific to this release, and the out-of-scope items are justified and protect the timeline.
• Testing types mapped to the feature (Topic 4) — 1: types named generically or not at all · 2: relevant types listed and tied to checkout/promo · 3: each type is mapped to a concrete part of the flow, and types not being run are explicitly flagged with an owner.
• Environment / device / browser matrix — 1: vague ("test on browsers") · 2: names specific environments and devices · 3: prioritized matrix justified by real traffic and feature constraints (e.g., Apple Pay forces iOS/Safari).
• Entry and exit criteria — 1: missing or unmeasurable · 2: present and mostly checkable · 3: binary, gate-able criteria a release manager could tick off, including a defect-severity bar.
• Risk-based prioritization — 1: flat list, no risk reasoning · 2: prioritizes some areas · 3: a likelihood × impact → risk → P1–P3 table where money/order-completion and new code paths correctly rise to the top, with rationale.
• Professional craft & honesty about limits — 1: bloated, generic, or pretends full coverage is possible · 2: clear, scannable, one-to-two pages · 3: tight and portfolio-ready, names assumptions/dependencies, and states what gets cut first if time runs short.