Capstone: test the FoodDash 2.0 release
Put everything together on a realistic project: read the brief, plan, write test cases, explore a buggy app, report what you find and make the release call.
The scenario
Your first week as a tester at FoodDash. Release 2.0 ships Friday.
FoodDash is a food delivery app: find a restaurant, fill a cart, pick a delivery time and track the courier to your door. Version 2.0.0 is the biggest update in a year: a redesigned checkout, address autocomplete, German and Serbian, dark mode and new notification settings.
Your lead, Sara, drops a link in your chat on Monday morning: "Here's the brief and the test build (2.0.0, build 412). Can you plan it, test it and tell us by Thursday whether we can ship? Product decides on Friday morning based on your report."
The build has 24 hidden bugs, just like a real release candidate: some obvious, some only visible on a small screen, in another language, offline or with a screen reader. Nobody will tell you where they are.
Your five phases
Your work is saved in this browser as you go, so you can stop and come back any time. The whole project takes about 2 to 2½ hours.
- 11. Read the brief 10–15 minProduct overview, release notes, user stories with acceptance criteria, test account and known issues.
- 22. Write a test plan 20 minA one-page plan: scope, risks, devices, test data, entry and exit criteria. Then compare with a model plan.
- 33. Write test cases 25 minFive test cases for the cart and checkout, checked against a rubric and eight model cases.
- 44. Test the app 45–60 minAn exploratory session in the FoodDash 2.0 build. Report every bug you find, right inside the app.
- 55. Report and recommend 15 minA test summary report with a go / no-go recommendation for Friday's release.
- Results and certificateYour scorecard: bugs found by category, how well you rated them, hints for what you missed, and a printable certificate.
Saved in this browser only. No sign-up.
What you will practice
- Read a spec like a testerFind the rules you can test against (your oracles), and the gaps nobody wrote down.
- Plan by riskDecide what matters most when time is short, and what you will deliberately not test.
- Write test casesSpecific steps, one check per case, measurable expected results, negative and edge cases.
- Explore with a charterA time-boxed session with a mission, heuristics and notes, in a realistic mobile app.
- Report bugsClear titles, steps to reproduce, expected vs actual, and an honest severity and priority.
- Recommend go / no-goSummarize what you tested and what is still risky, so the team can decide about Friday.