Test Plan, Capstone, and Getting Paid
Today you do the work the way a real QA sprint is done — under a clock — and you leave with a document you can send to a stranger.
- Write a test plan for a real feature and defend your priorities
- Run a timed bug hunt and score yourself against a professional rubric
- Produce a portfolio document and know exactly where to send it
1. What a test plan is, and why it exists
A test plan is a structured list of everything that must be checked before a feature ships — organised so nothing important is forgotten, and written clearly enough that a tester who has never seen the project can pick it up and know what to do. It is the difference between "I tested the checkout" and being able to say precisely what you tested, what you did not, and why.
2. Risk-based prioritisation — because you will never have enough time
You will almost never be given time to test everything equally. So you spend your hours where failure is most likely and most expensive. The question is always the same: if this breaks, how many people are affected and how badly?
A payment step affects every customer and costs money directly — test it hardest, test it repeatedly, test it on a bad connection. A typo in a footer link affects almost nobody — test it last, if at all. Testers who cannot prioritise spend three days on the footer and ship a broken checkout.
3. What goes into the plan
- Feature name and scope — exactly what is being tested, e.g. "Checkout — Apply Coupon Code".
- Priority list — the areas inside that feature, sorted Critical / High / Medium / Low, each with one line of reasoning.
- Test cases — the actual list, in the five-part format from Day 2.
- Out of scope — what you deliberately are not testing this round, and why. This part protects you. When something you never agreed to test breaks, the plan is the receipt.
- Choose the checkout flow of any online store you know.
- List 3 Critical, 3 High and 2 Medium/Low items to test, each with a one-line reason for its priority.
- Write 8 full test cases covering those priorities, in the five-part format.
- Name one thing you are deliberately leaving out of scope, and explain why in one sentence.
Ask yourself: which single item on your Critical list would do the most damage to the business if it broke? If your answer is not obviously the most expensive failure, re-sort your list.
4. The capstone: a timed hunt, exactly like a paid sprint
This is the piece that becomes your portfolio. Generate a harder practice target, set a timer, and work like you are being paid for the hour — because on your first gig, you will be.
Generate the exam, sit it, then have it marked
Step 1 — build the capstone app:
Build me a single-file HTML page (no libraries, works offline)
for a fake service called "SwiftPay" — a simple money transfer
app with: a login form, a balance display, a "Send money" form
(recipient account number, amount, narration), a transaction
history list, and a settings page with a profile form.
Plant exactly 5 BUGS across these categories:
- one functional bug
- one edge-case bug tied to a boundary value or repeated action
- one responsive/UI bug that only appears on a narrow screen
- one that only shows itself when an input is empty or unusual
- one silent bug that only appears in the Console
Make it harder than a beginner exercise: none of the bugs should
be visible on a casual click-through. Do not describe the bugs.
No revealing comments in the code. Put the ANSWER KEY in a
separate code block at the very end.
Step 2 — set a timer for 45 minutes and hunt. No reading the code, no peeking at the key. Write full eight-part bug reports as you go, not afterwards — writing while hunting is the real skill, and it is what the clock is for.
Step 3 — mark yourself against the rubric below, honestly. Then paste your reports back to the AI with this:
Here is the answer key you produced, and here are the bug
reports I wrote during a 45-minute timed hunt.
Score me out of 100 using this rubric:
- Bugs found (40): how many of the planted bugs I correctly identified
- Report quality (30): are all 8 parts present, clear and specific
- Severity accuracy (15): does my severity match the real impact
- Reproducibility (15): could another tester follow my steps exactly
For each planted bug I missed, tell me what I would have had to
do differently to find it. Be specific about the technique, not
encouraging about my effort.
| Criteria | Points | What is being judged |
|---|---|---|
| Bugs found | 40 | How many of the planted bugs you correctly identified |
| Report quality | 30 | All eight parts present, clear and specific |
| Severity accuracy | 15 | Severity assigned matches the real impact |
| Reproducibility | 15 | Could another tester follow your steps and see the same bug? |
Score under 50 on your first attempt? That is normal, and it is information, not a verdict. Generate a fresh app and go again. The second run is always dramatically better than the first, and that jump is the thing you should notice about yourself.

5. Where this turns into money
| Where to look | What to expect |
|---|---|
| Upwork, Fiverr | Short QA gigs — "test my app before launch". Small first, but a completed job with a good review is worth more than a certificate. |
| HackerOne, Bugcrowd | Public bug bounty programmes. Harder and more security-focused, but they pay for results, and nobody asks about your degree. |
| Junior QA roles | In-house and agency positions. These rarely require a degree — they require evidence that you can find and describe bugs. |
| Your own network | Someone you know has a website with broken things on it. Test it free, send a clean report, ask for a referral. This is how a surprising number of QA careers actually start. |
- Compile your capstone bug reports into one clean document — Google Docs is fine, PDF is better.
- Add a one-paragraph summary at the top: what you tested, how long you spent, how many bugs you found and their severity spread.
- Add your screenshots. Every report gets its evidence.
- Add one honest closing line about what you would test next if you had more time. Clients notice that line more than anything else in the document.
- Name it properly —
QA-Report-SwiftPay-YourName.pdf— and keep it. This is the first item in your testing portfolio.
Q1. What does risk-based prioritisation actually mean?
Reveal the answer
Spending most of your testing time on whatever is most likely to break, or most expensive if it does — judged by how many users are affected and how badly.
Q2. Which of these belongs at the top of a test plan's Critical list?
Reveal the answer
The payment step that could charge customers incorrectly. Not the misaligned footer icon, not the tooltip that appears half a second late.
Q3. In the capstone rubric, what is "reproducibility" measuring?
Reveal the answer
Whether another tester could follow your steps exactly and see the same bug — not how many bugs you found, and not how many screenshots you attached.
Q4. Name two realistic ways a tester earns money, and one difference between manual and automation testing.
Reveal a good answer
Any two of: in-house QA role, agency work, freelance gigs on Upwork or Fiverr, bug bounty platforms like HackerOne or Bugcrowd. And: manual testing is a human performing and judging the tests directly; automation testing uses scripts and tools to repeat those same tests without a person running them each time.
The honest section: where AI helps you, and where it will lie to you
You have now used AI five different ways in five days. It is worth being precise about what actually happened there, because "use AI" is advice that gets people into trouble.
| AI is genuinely excellent at | AI will quietly fail you at |
|---|---|
| Generating unlimited practice apps with planted bugs | Knowing whether something is actually broken — it cannot see the screen |
| Translating an error message into plain English | Judging severity, which depends on the business, not the code |
| Reviewing your report as a hostile reader | Writing the report — it will invent details it did not witness |
| Expanding a list of edge cases you already started | Producing the first list, which is where your judgment lives |
| Explaining an unfamiliar term instantly, without embarrassment | Telling you it does not know. It will guess, confidently, in the same tone as the truth. |
The pattern is consistent: AI is superb at producing raw material and pressure-testing your work, and unreliable at observing reality and making judgment calls. Testing is a job made almost entirely of observing reality and making judgment calls. That is exactly why testers are not the ones AI replaces — but a tester who uses AI well practises five times faster than one who does not. Be that one.

What "finished" actually looks like
If you did the work rather than the reading, you can now do all of this without help. Tick honestly — the unticked ones are your next week.
- Explain how a website works end to end, using the right words, out loud
- Open DevTools and use it to investigate a problem, not just to look busy
- Think in edge cases automatically, without being prompted
- Write test cases and a basic test plan for any feature you are handed
- Write a bug report a developer can act on with zero follow-up questions
- Point at one document and say "this is my work" when someone asks
What to learn next
This course deliberately covered manual testing — the thinking skill everything else is built on. Neither of these next steps is required to start earning, but both raise your rate:
- Automation testing with Selenium or Playwright — writing scripts that run your same tests over and over without you. The people who write good automated tests are the people who first learned to test by hand; automation only repeats the thinking you already did.
- API testing with Postman — checking the backend directly, without going through the frontend at all. Remember the waiter and the kitchen? This is walking into the kitchen.
If you want structure and people around you while you build the coding side of this, our frontend development course and data analyst course both start from zero the same way this one did. You can see everything currently open on the courses page.
Frequently asked questions
Do I need to know how to code to become a software tester?
No. Manual testing — the whole of this course — requires no coding at all. You need to understand how the pieces fit together, which is what Day 1 was for. Coding becomes useful later, when you move into automation, and by then you will have a reason to learn it.
Can I really learn software testing in 5 days?
You can learn the foundations and produce your first real work in five days — that is exactly what this course does. You will not be a senior QA engineer. You will be someone who can find bugs, write reports professionals respect, and honestly show a client what they can do. That is a genuine starting point, and it is more than most people applying alongside you will have.
Do I need a degree or a certificate to get a QA job?
Junior QA roles very rarely require a degree. What they require is evidence. A folder of clean, specific bug reports on real or simulated products does more for you in an interview than any certificate, because it answers the only question the interviewer actually has: can this person find things?
What tools do I need to start?
A laptop, a browser with DevTools (Chrome, Edge or Firefox — all free), somewhere to write, and a free AI chatbot for the drills. That is the entire toolkit for everything in these five days.
Will AI take software testing jobs?
AI is very good at generating tests and terrible at deciding what matters, and testing is mostly deciding what matters. What is genuinely changing is speed: a tester who uses AI to generate practice targets, review their writing and expand their thinking works far faster than one who does not. Learn it as a tool, not as a replacement for your own eyes.
You finished. Now go break something on purpose.
You have the mindset, the tools and a portfolio document. The next step is repetition — a new practice app, a new hunt, a new report, every week until it is a reflex. And if you want to build the technical side properly, with tutors and a cohort rather than alone, that is what Webbo3 Academy is for.
See what's open at Webbo3 →Written by the instructors at Webbo3 Academy. Share this with the person who keeps saying they want to get into tech but does not know where to start — five days and a browser is genuinely all this one takes.