Become a Software Tester: Free 5-Day Course

Almost every app you have ever cursed at — the bank app that spun forever, the checkout that charged you twice, the form that swallowed your details and said nothing — reached you because somebody did not test it properly. That job, finding the broken thing before a real customer does, is called software testing, and it is one of the very few tech roles you can start with no degree, no coding background, and nothing but a laptop, a browser and a stubborn mind.

This is a complete free course. Not a teaser, not a list of links. Five days, five sittings of about 90 minutes each, and at the end of it you will have written real test cases, hunted down a bug that was deliberately hidden from you, filed a bug report a developer could actually act on, and built the first piece of a portfolio you can show a client. You will also do something most testing courses have not caught up to yet: you will use AI as your practice partner, your sparring opponent and your bug factory — while learning exactly where it helps and where it quietly lies to you.

Everything below is designed to be done, not read. Read a section, then do the thing in the box. Testing is not a subject you understand. It is a reflex you build.

The 5-Day Map

One warning before Day 1. There is a version of this course you can do in ninety minutes total, by reading all five days and doing none of the exercises. That version teaches you the vocabulary of testing, which is exactly enough to fail an interview confidently. The gap between someone who knows about testing and someone who gets hired to test is entirely in the practicals. Do them.

1. Website, web app, mobile app — and why the difference matters to you

A website is something you mostly read. A blog, a news site, a company's About page. You click, you scroll, you leave. You change almost nothing.

A web app also lives in a browser, but it does things for you. You log in, you submit data, the page changes based on what you did. Gmail is a web app. So is Instagram on your laptop. So is any food-ordering platform. The difference is not the technology — it is how much you can change inside it.

A mobile app is installed on the phone itself, from the Play Store or App Store, and it can reach things a browser usually cannot: your camera, your GPS, your contacts, push notifications.

Why a tester cares: different kinds of software break in different places. A web app breaks when you press the browser's Back button after paying. A mobile app breaks when you rotate the phone mid-form, or when NIN verification runs and your network drops. Knowing what you are holding tells you where to go looking for trouble.

2. The restaurant: client, server, frontend, backend

Every app is a conversation between two computers: your device and a computer somewhere else. The clearest way to hold this is a restaurant.

You sit at a table and tell the waiter what you want. The waiter carries your order to the kitchen. The kitchen cooks it. The waiter brings the food back. You never enter the kitchen — you only experience ordering, waiting, and receiving.

That is the whole architecture of nearly everything you will ever test. When a tester says "I think it's a backend issue", they are saying: the waiter delivered my order fine, but the kitchen sent back the wrong plate.

3. What really happens when you click "Login"

This is the single most useful mental model in this entire course. Read it slowly. Almost every bug you will find in your career lives somewhere in these seven steps.

1. You type your email and password. (Frontend — HTML built the form, CSS styled it, JavaScript is watching for your click.)
2. You click Login. JavaScript grabs what you typed and packages it into a request.
3. That request travels over the internet to the backend. (API.)
4. The backend receives it and asks the database: does a user with this email exist, and does the password match?
5. The database answers: match, or no match. (Your password is not stored as readable text — it is stored scrambled, so that even the company cannot read it.)
6. The backend sends a response back through the API: success with a login token, or failure with an error message.
7. The frontend receives that response and either shows your dashboard, or shows "Incorrect email or password."

Now look at how many places that can go wrong. The frontend might send the email with a trailing space. The backend might compare passwords case-sensitively when it shouldn't. The database might be slow and the frontend might give up waiting. The response might be correct but the frontend might display nothing at all — so the user clicks Login six more times. You do not need to write the code. You need to know where to point.

4. Meet DevTools — your new best friend

Every browser has a hidden panel called Developer Tools. Right-click anywhere on a page and choose Inspect, or press F12 on Windows, or Cmd + Option + I on Mac. Three tabs matter today:

• Elements — the actual structure of the page. Hover over lines here and the matching part of the page lights up. You can even edit text temporarily, which is how people make those fake screenshots.
• Console — messages and errors the page is producing in the background. Red text here almost always means something broke.
• Network — every single request the page makes to the server, and whether each one succeeded or failed. Refresh a page with this open and watch the whole conversation happen.

Here is the thing that should genuinely excite you: a page can look completely normal to every user on earth while the Console is full of red errors and the Network tab shows requests failing. Those failures are real bugs. Most people will never see them. You now can.

5. The names you will keep hearing

You are not going to write code in this course. But you will sit in meetings where these words fly around, and looking blank costs you credibility. Here is roughly what each one is for.

I am learning software testing. I found this error in my browser's
Console tab on a live website. Explain it to me in plain English:

1. What does this error actually mean?
2. Is this a frontend problem or a backend problem?
3. Would a normal user notice anything, or is it invisible to them?
4. On a scale of "cosmetic" to "serious", how bad is it and why?

Do not give me code fixes. I am the tester, not the developer.

ERROR: [paste the red text from your Console here]

Tick before you move on:

1. What a tester actually does all day

A tester uses software the way a real person would — and also the way a careless, rushed, confused, dishonest or very unlucky person would — before real customers get the chance. Then they write down three things: what they did, what they expected, and what actually happened. When the last two do not match, that is a bug.

A normal working day is usually some mix of three activities:

• Regression testing — running through a checklist of existing features after an update, confirming nothing that used to work has quietly stopped working.
• Exploratory testing — poking at a brand-new feature with no checklist at all, just to see what happens.
• Focused breaking — taking one feature and deliberately trying to destroy it.

2. How testers actually earn

3. The one question that separates a sharp tester from everybody else

A normal user does the expected thing, once, carefully. A tester does the unexpected thing — repeatedly, incorrectly, at the wrong time, in the wrong order, on purpose. That is the entire job description, and it is a habit you can build in a week.

4. Edge cases — the seven categories

An edge case is an unusual, extreme or unexpected situation sitting right at the edge of what the software was built to handle. Software is nearly always built and checked for the normal path. Your value as a tester lives entirely outside that path.

Sit with a few of these, because they are not hypothetical. "Clicking Buy 100 times fast" is how people discover that a payment endpoint has no protection against repeat submissions — a bug that costs real customers real money. "Losing internet mid-checkout" is the single most common real-world condition on the African internet and the single least tested one. And "two people buying the last item at once" is how an online store ends up selling stock it does not have and having to refund and apologise.

5. Writing a test case that another human can actually follow

A test case is a documented, repeatable check. Five parts, always:

Act as a senior QA engineer reviewing a junior tester's work.

Here is a signup form with these fields: Full Name, Email,
Phone Number, Password, Date of Birth.

Here is MY list of edge cases:
[paste your 15 here]

Now:
1. Which of my cases are genuinely strong? Say why.
2. Which are weak or duplicated? Say why.
3. What are 8 edge cases I missed that a real user could
   realistically hit — especially around network failure,
   concurrency and very long or special-character input?
4. For each one you add, tell me what could go wrong in the
   database or the backend if it is not handled.

Be blunt. Do not flatter me.

1. Functional testing, plainly

Functional testing asks one question of every single thing on a screen: does this do what it says it does? Does the button go where it claims? Does the search bar actually search? Does "Forgot Password" lead anywhere useful, or to a dead page? It is the most basic layer of testing and it is where essentially every testing job starts.

The method is boring and that is the point. You go left to right, top to bottom, and you touch everything. Testers who "have a feel for where bugs are" got that feel by first being systematic a few hundred times.

2. Status codes — the numbers that tell you the truth

Every request your browser sends comes back with a three-digit status code. You will see these for the rest of your career:

The move that makes you valuable: keep the Network tab open while you browse normally. When a page looks completely fine but you can see a 500 or a 404 quietly failing behind it, you have just found something no ordinary user would ever have reported. This is the difference between "I clicked around" and "I tested it".

3. The hidden bug — and why one click proves nothing

Real bugs are rarely waiting politely on the surface. The dangerous ones hide behind conditions:

• A Buy button that works perfectly the first 98 times and throws an error on the 99th.
• A form that accepts everything correctly except a name of exactly one character.
• A page that is flawless until the browser is narrower than a certain width, at which point a button slides behind another element and becomes unclickable.
• A feature that only fails when the connection is slow enough for two requests to overlap.

Nobody hands a tester a list of bugs to go confirm. You are handed a product and told: something in here is wrong. Find it. Today you are going to build exactly that situation for yourself — and you are going to build it with AI, which is the most useful thing AI does for a learning tester.

Build me a single-file HTML page (HTML, CSS and JavaScript all
in one file, no libraries, no internet needed) that works as a
small fake online shop called "PracticeMart".

It must have: a product list with 4 items, an "Add to cart"
button on each, a cart counter in the header, a quantity field,
a coupon code box, and a checkout form asking for full name,
email, phone number and delivery address.

Now plant exactly 4 BUGS in it, of these 4 different kinds:
1. One functional bug (something visibly does the wrong thing)
2. One edge-case bug that only appears after a repeated action
   or at an exact boundary value
3. One responsive bug that only appears below 500px width
4. One silent bug that logs an error to the browser Console but
   looks completely fine on screen

Rules:
- The page must look totally normal on a casual click-through.
- Do NOT tell me what the bugs are.
- Do NOT put comments in the code describing them.
- At the very end, output the answer key inside a code block
  labelled ANSWER KEY that I will not scroll to until I am done.

Give me the full file, ready to save as practicemart.html.

1. Three contexts almost nobody tests

Mobile and responsive view. Most sites are designed for a big desktop screen first and squeezed down afterwards, and the squeezing is where things break. In DevTools, click the small phone/tablet icon (Toggle Device Toolbar) and preview the page at phone width. Look for overlapping text, buttons pushed off-screen, menus that will not open, and forms you cannot submit because the button is under the keyboard.

Slow network. In the Network tab there is a dropdown that usually says "No throttling". Change it to Slow 3G. Now reload. This is not an edge case in Nigeria, Ghana or Kenya — it is Tuesday. The question you are answering is: does the app show a loading indicator that tells the user to wait, or does it just sit there looking frozen and broken until the user gives up, closes it, and tells their friends the app does not work?

Keyboard only. Put the mouse down. Navigate the page using only Tab, Shift+Tab, Enter and the arrow keys. Can you reach every field and button? Can you always tell which element is currently selected? Some users navigate this way permanently, including people with motor impairments and people using screen readers. When keyboard navigation is broken, those users simply cannot use the product at all — and that is both an accessibility failure and, increasingly, a legal one.

2. Why most bug reports get ignored

A bug report is only useful if a developer can read it once and immediately understand what went wrong and how to see it themselves. A vague report — "the buy button is broken, please fix" — goes to the bottom of the pile, because reproducing it will cost the developer thirty minutes of guessing. A precise report gets fixed the same day, and gets you hired again.

3. The eight parts of a report that gets fixed

1. Title — short, specific, searchable. Not "button doesn't work" but "Buy button throws 500 error on the 99th consecutive click".
2. Environment — browser and version, operating system, device, the exact URL, the date and time.
3. Steps to reproduce — numbered, exact, repeatable. Anyone following these should see the same thing.
4. Expected result — what should have happened.
5. Actual result — what really happened, precisely.
6. Severity / priority — how bad is it, honestly.
7. Evidence — screenshot, screen recording, or the Console log. A picture ends all argument.
8. Frequency / notes — every time, or sometimes? Anything else you noticed nearby?

4. Severity, judged honestly

A junior tester marks everything High because everything feels urgent when you just found it. A tester people trust marks the misaligned button Low — and precisely because they do, everyone believes them when they mark something Critical.

5. Bad report versus good report

You are a busy senior developer. A tester just sent you the bug
report below. You have never seen this product and you cannot
ask any questions.

Read it and answer strictly:
1. Following ONLY these steps, could you reproduce this bug?
   Where exactly would you get stuck or have to guess?
2. List every piece of information that is missing or vague.
3. Is the severity justified by the described impact, or is it
   over-stated? Say what you would change it to and why.
4. Rewrite the title so it is specific and searchable.
5. Score the report out of 10 for reproducibility, and tell me
   the single change that would raise the score the most.

Be strict. A generous review helps me nothing.

BUG REPORT:
[paste yours here]

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.

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.

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.

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.

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

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.

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.

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.

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.