When most people hear “QA” they picture someone at the end of the line, clicking through the app, catching bugs before release. That version exists, but it is the smallest slice of the job.
QA is the person on the team who is paid to ask, out loud, one question. What could go wrong here, and how would we know?
You ask it before the work is built. You ask it while it is being built. You ask it after it ships. Some days you ask it by testing a screen. Some days you ask it by reading a story and noticing step three has no error state. Some days you ask it by looking at a dashboard and noticing the numbers do not match what the app is telling users.
QA is not a clicking job. It is a thinking job that sometimes uses clicks.
How this course works
This course is not reading. Every lesson has you doing the actual work, and all of it happens in one place: Tumble Kitchen, a small Jamaican food shop I keep on my site purely for practice. It has a search, a cart, a discount code, and a sign-in. It also has bugs. Real ones, left in on purpose, and finding them is part of the course.
Each lesson takes twenty to thirty minutes, and every one ends with a “Do this today” that leaves you holding something: a list, a case, a report, a decision. Keep them together, because by Day 10 they add up.
By Day 10 you will have produced, with your own hands:
- A set of written test cases with boundary coverage.
- Real bug reports, for real bugs you found yourself.
- An exploratory testing charter and session notes.
- A release summary with your own ship or do-not-ship call.
That is a small portfolio, and it is more evidence of real QA thinking than most people bring to their first interview. When the ten days are done, your final email gives you a private assessment code. You answer 25 scenario questions against a visible clock, complete the applied tasks, test the supplied app, and submit the practical work for rubric review. The certificate is issued only after the work is approved.
The ten days
- Day 1. How testers think, practised on the store.
- Day 2. User stories and acceptance criteria: finding bugs before anything is built.
- Day 3. Writing test cases a stranger could run.
- Day 4. Boundaries and equivalence: choosing the few values that do the most work.
- Day 5. You find your first real bug and file a report a developer would thank you for.
- Day 6. Testing beyond the screen: the network tab, the data, and a second bug.
- Day 7. Exploratory testing with a charter, a timer, and honest notes.
- Day 8. Where QA sits inside a real team’s week.
- Day 9. The map of what to learn next.
- Day 10. The capstone: test a feature end to end, make the release call, then unlock the assessment and practical review.
Two things to know before you start
- You do not need to be technical to be good at this. You need to be curious, careful, and honest.
- QA is a career, not a stepping stone into something else. The people who treat it as a stepping stone rarely get good at it.
Do this today
Open Tumble Kitchen and just use it for five minutes, the way a normal shopper would. Search for something. Add a dish to your order. Do not try to test it yet. Tomorrow you will look at the same store with completely different eyes, and the difference between the two visits is the whole point of this course.
Talk tomorrow.