QA Engineer Capstone

The idea: Knowledge becomes skill only when you do the work. In the capstone you own QA for one feature area and carry it through the entire testing workflow, producing the real artifacts a tester makes on the job. By the end you'll have a portfolio that proves — to yourself and to employers — that you can take a feature from requirements to a defensible go/no-go recommendation, not just describe testing in the abstract.

How it works: Each deliverable unlocks after the syllabus topic that teaches its skill. You produce the artifact (a template is provided), submit it, and the app's AI reviews it against a rubric, gives you specific feedback, and lets you revise until it's solid. Finished deliverables assemble into your portfolio.

Your scenario: Ship-Quality QA for ShopSphere Checkout

You don't pick a product for this capstone — you're handed one, the way a new hire is. You own QA for the checkout-and-promo-code flow of ShopSphere, a mid-size e-commerce web and mobile app shipping a new release.

ShopSphere is a 40-person online retailer launching a redesigned checkout with a new promo-code field, guest checkout, and Apple Pay. You join the QA team two weeks before release. Product gives you a short requirements spec and Figma mockups; engineering pushes daily builds to a staging environment; bugs and tickets live in Jira and test cases in TestRail. The team works in two-week agile sprints and expects QA to shift left — review the spec, raise risks early — and deliver a clear release recommendation at the end. You carry this same checkout feature through every deliverable, so the work forms one coherent, portfolio-ready story.

Capstone fixtures (use these everywhere)

This is the single source of truth for the scenario. Every deliverable's worked example uses these exact values — the same build, the same URLs, the same promo codes — so your six artifacts describe one feature, not six slightly different ones. A grader scanning your portfolio should never see the build number or a promo code change between documents; when it does, it reads as carelessness, which is the opposite of what QA is selling. When you write your own artifacts, either reuse these fixtures verbatim or, if you change one, change it everywhere and say why.

Release under test

Fixture	Canonical value
Product / feature	ShopSphere redesigned checkout + promo-code field, guest checkout, Apple Pay
Release	Sprint 14, target end-of-sprint (the "v2.4" checkout release)
Build under test	2.4.0-rc3 (the release candidate you test against; an earlier 2.4.0-rc2 exists and is referenced only where a re-test/Reopened bug needs it)
Jira project key	SHOP (tickets read SHOP-####)
Test window / decision	Test window Jun 10–14 2026; release-decision date Jun 16 2026

Environments & URLs

Surface	Canonical URL
Staging web app (UI testing)	https://staging.shopsphere.com
Staging API (endpoint testing, D6)	https://staging-api.shopsphere.com
Promo endpoint	POST /api/v1/cart/{cartId}/promo · body { "code": "<STRING>" }
Fixed test cart (API)	cartId = cart_7f3a91, one item, subtotal $22.00 (so discount math is verifiable)
UI standard cart	3 × "Aurora Desk Lamp" @ $16.00 = subtotal $48.00, free shipping over $35.00

Canonical promo codes — these are the only codes used across all six deliverables. Currency is USD; percentages apply to the subtotal before tax/shipping.

Code	Effect	Min cart	Use rule	Status
SAVE20	20% off subtotal	$20.00	multi-use, not stackable	Active, in-date
WELCOME15	$15.00 off	$50.00	single-use per account	Active, in-date
BIG50	50% off subtotal	$50.00	multi-use, not stackable	Active, in-date
SUMMER20	alias of SAVE20 (20% off)	$20.00	multi-use; entry is case-insensitive	Active, in-date
SUMMER19	20% off	$20.00	multi-use	Expired 2026-05-31
FAKE99	—	—	—	Not in the system (unknown code)

Magic numbers that show up in the boundary work: promo codes are 4–10 chars, uppercase letters + digits; valid line-item quantity is 1–10; free shipping unlocks at a $35.00 subtotal (so the $48.00 UI standard cart above ships free, while the boundary cases in Deliverable 3 probe right at $34.99 / $35.00 / $35.01). These are the edges the coverage matrix (Deliverable 3) pins.

The deliverables (your capstone arc)

#	Deliverable	Unlocks after	The skill it proves
1	Risk-based test plan for the checkout release	Topic 5 (Writing test cases and test plans)	Setting scope, criteria, and risk priority before testing starts
2	Test-case suite for the promo-code & checkout flow	Topic 5 (Writing test cases and test plans)	Turning requirements into a runnable, repeatable test suite
3	Test-design coverage matrix (equivalence & boundary)	Topic 7 (Test design techniques)	Covering more with fewer, well-chosen tests instead of brute force
4	Professional bug report pack	Topic 8 (Bug tracking and test management tools)	Writing reproducible, triage-ready defect reports
5	Test execution & release sign-off report	Topic 8 (Bug tracking and test management tools)	Reporting results and making a defensible go/no-go call
6	API smoke-check notes for the promo endpoint	Topic 9 (An introduction to automation and APIs)	Testing below the UI, where QA grows toward automation

Each builds on the last: the test plan sets scope and risk; the test-case suite turns that scope into runnable cases; the coverage matrix sharpens those cases with equivalence partitioning and boundary value analysis; executing them surfaces the defects in your bug report pack; the execution report rolls run results, open defects, and residual risk into a go/no-go call; and the API smoke checks show you can verify the promo logic below the UI. Together they tell one coherent QA story about the same checkout feature.

What each deliverable is

1. Risk-based test plan — A one-to-two-page plan defining scope (in/out), the testing types you'll apply, target environments/devices/browsers, entry and exit criteria, and a risk-prioritized list of what to test first. The strategy a QA lead signs off before testing starts. (~75 min, template: test-plan.md)
2. Test-case suite — A structured suite of 12–15 test cases (title, preconditions, numbered steps, expected result) covering the happy path, edge cases, and error/negative cases for checkout and promo codes. The executable spec a tester runs each release, formatted as it would live in TestRail or a spreadsheet. (~90 min, template: test-case-suite.md)
3. Test-design coverage matrix — A matrix applying equivalence partitioning and boundary value analysis to the promo-code and quantity/amount fields, showing the classes, the boundary values tested, plus a short exploratory-testing charter. (~60 min, template: test-design-matrix.md)
4. Professional bug report pack — Three Jira-ready bug reports for defects found while executing your suite — each with a specific title, minimal steps to reproduce, expected vs. actual, environment, evidence (screenshot/console error), severity/priority, and the correct bug-life-cycle status. (~75 min, template: bug-report.md)
5. Test execution & release sign-off report — A test-run summary with pass/fail counts against your suite, open defects by severity, regression-check results, residual risk, and a clear go / no-go release recommendation with justification. The document QA hands to the release manager. (~60 min, template: test-execution-report.md)
6. API smoke-check notes — A short set of Postman-style checks for the apply-promo-code endpoint: the request, the expected response, two negative cases (invalid/expired code), and a note on why API-level testing is faster and more stable than via the UI. (~45 min, template: api-smoke-checks.md)

What "done" looks like

A complete capstone is six artifacts about one feature, each passing its rubric, assembled into a portfolio you can link from your resume and walk through in interviews. By the end you can hand a release manager a defensible go/no-go recommendation backed by a plan, a suite, real bug reports, and run results — exactly the artifact set a real tester produces for one feature area. When you reach the interview prep (Topic 10, Landing the QA job) and the program schedule, you'll practice presenting these artifacts the way you would to a hiring manager.

Tips

• Keep it real and specific. "Promo code doesn't work" is a weak bug; "Expired promo code SUMMER19 is accepted and a 20% discount is applied at checkout (expected: rejected with 'This code has expired')" is QA thinking. (Note SUMMER19 is the expired code in the Capstone fixtures — SUMMER20 is the active alias of SAVE20; mixing them up is exactly the kind of fixture drift graders catch.)
• Reuse your earlier work. The risks you flag in the test plan should drive what you prioritize in the suite; the cases you write should be the ones you execute and report on. Graders (and employers) love a coherent thread — the same checkout feature visibly carried end to end.
• Cover the angles. For each area think happy path, edge, negative, usability, compatibility, and security — the same lens QA interviewers probe with "how would you test this?"
• Use the templates in ../templates/ as starting points, and revise based on the AI feedback rather than aiming for perfect on the first try (that's the whole loop).