Yesterday you ticked off what this course already covered on the roadmap. Today is the whole job, compressed. No new theory. You take one feature of Tumble Kitchen, test it the way a professional would, and end with the sentence every tester eventually has to say out loud: ship it, or not yet.
The assignment
Your feature is the discount flow, end to end: cart, IRIE20, totals, checkout.
- Design (20 minutes). Write eight to twelve test cases in the Day 3 shape, “Verify that” titles, exact data, specific expected results. Cover the happy path, the boundary at 10,000 exactly, an invalid code, applying before the cart has anything in it, and what happens to the discount when items are removed. You know two of these will fail. Write the cases anyway; a test case that catches a known bug is doing its job.
- Execute (20 minutes). Run every case against the store. Mark each one passed or failed, with a one-line note. No skipping the awkward ones.
- Explore (20 minutes). One charter for whatever your cases did not cover. Timer, notes, debrief.
- Report. Your two failing cases point at the two bugs you found this week. Tighten both reports until a stranger could reproduce them from the text alone.
- Decide. Write the release summary and make the call.
The release call
This is the part that makes it real. Open my QA Release Summary Template and fill it in from your artefacts: what you tested, what you did not, what you found, what risk remains, and your recommendation.
Here is the uncomfortable truth about that last field: there is no formula. A boundary bug that short-changes customers at exactly 10,000 JMD and a total that goes stale on remove. Ship, hold, or ship with a warning: reasonable testers argue all three ways. What matters is that your recommendation names the evidence, states who is affected, and takes a position. QA does not always make the final call, but QA makes the call sayable. Decide out loud. “Ship, with this evidence” or “not yet, because of this gap.” Either is fine. Silence is not.
Your self-check
Before you call it done, score yourself honestly:
- Every test case has a “Verify that” title, exact data, and an expected result someone could disagree with.
- The boundary at exactly 10,000 has its own case, not a vague “test the discount”.
- Both bug reports say who is affected and include the detail that points at the cause.
- The charter has a debrief with “what I would explore next”.
- The release summary takes a position and backs it with the evidence above.
If all five hold, you did not learn about testing these ten days. You tested.
The assessment and reviewed certificate
Your final course email contains a private code tied to this course and email address. Use it to unlock 25 scenario questions, with five questions in each competency section. You need 20 correct overall and at least three correct in every section.
- The questions are timed: 40 minutes, with the countdown on screen.
- Expect more than one format: pick one, pick two, put steps in order, and read the evidence before you answer.
- The practical work is untimed. Prepare it before you start the questions.
Then complete the three applied responses and submit your QA practical: requirement gaps, at least eight test cases, an exploratory charter and notes, two reproducible bug reports, and your release recommendation. I review it against the published rubric. Submission alone does not issue a certificate.
Unlock the assessment with your final-email code
If a question trips you, the lesson it came from is one email back in your inbox, and the quiz will still be there when you return.
What you are holding now
All of it on one product:
- A promise list.
- A written test suite with boundary coverage.
- Two reproducible bug reports.
- An exploratory session with a debrief.
- A triage case.
- A release recommendation.
- A certificate.
Keep it. Reference it in interviews. “I found a boundary bug in a discount engine and here is my report” is a better answer than any certificate alone, and now you have both.
Thank you for spending ten days with me. The next course, Test Automation Basics, takes the exact cases you wrote today and teaches you to make a machine run them on every change. Your discount boundary case becomes your first automated test that finds a real bug, which is the best first automated test anyone can write.
If you or your team wants help doing this on real work, my work with me page is open. Otherwise, my newsletter goes out every week, and it is where the practical stuff lands first. See you there.