Start Thinking Like Someone Who Breaks Things
Day 1 gave you vocabulary. Today gives you the actual skill. Everything after this is just this mindset with better tools.
- Describe what a tester does all day, and the four ways testers get paid
- Define an edge case and produce your own examples on demand
- Write a properly formatted test case that anyone could repeat
- Produce 10 real test cases for a live form, with no coding at all
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
| Route | What it looks like |
|---|---|
| In-house QA | You join a company's product team full-time or on contract as their quality gate. Junior QA roles very rarely require a degree. |
| Agency work | An agency tests client projects before launch. You test something different every few weeks. |
| Freelance gigs | Businesses post short-term QA jobs on Upwork and Fiverr — "test my app before Friday." |
| Bug bounties | HackerOne and Bugcrowd let companies publicly pay anyone who finds real bugs, often security ones. Some people earn a full income this way. |
3. The one question that separates a sharp tester from everybody else
"What happens if I do this wrong, weird, or too much?"
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.
| Category | What to try | Real example |
|---|---|---|
| Boundary values | The smallest, largest and exact-limit values a field allows | An age field accepting 0–120: try 0, 120, then -1 and 121 |
| Empty input | Leave a required field blank and submit anyway | Does it say what is missing, or fail silently? |
| Wrong data type | Letters in a number field, emojis in a name field | Type "banana" as your age. Then 😀 as your surname. |
| Rapid repeated actions | Click Submit or Buy many times, fast | Does it charge one customer three times? |
| Network failure | Kill the connection mid-action | Turn off data during checkout. Where did the money go? |
| Concurrency | Two things happening at the same instant | Two people buying the last item in stock in the same second |
| Special / very long input | Symbols like < > ' " and 10,000-character pastes | Paste a full chapter of a book into a "Full name" field |
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:
| Field | Meaning |
|---|---|
| Test Case ID | A short label like TC-01, so it can be referenced in a meeting |
| Steps | The exact actions in order, so anyone could repeat them |
| Expected Result | What should happen if the software is working correctly |
| Actual Result | What genuinely happened when you ran it |
| Status | Pass if expected matches actual. Fail if it does not. |
TC-01
Steps: On the signup form, leave the Email field empty and click Submit.
Expected Result: Form does not submit; an error message appears under the Email field.
Actual Result: Form submitted successfully with no email saved.
Status: FAIL
Beat the machine at edge cases — then beat it again
Here is how to use AI without letting it do your thinking. Write your own list first. Only then ask the machine, and see what you missed. Do it in this order or the exercise is worthless.
Step 1 — before you open any AI tool, spend ten minutes writing every way you can think of to break a signup form. Aim for fifteen.
Step 2 — now paste this:
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.Step 3 — the part that matters. Take the eight it gave you and go actually try them on a real form. You will find that some of the AI's suggestions are impossible to perform, some are irrelevant to that form, and one or two are excellent. That ratio is the lesson. AI is a very fast, very confident brainstorming partner with no eyes. You are the one who can see the screen.
- Pick any real signup or login form you can legally use — your own account on a site, or a public demo store.
- Write 10 test cases in the 5-part format, covering at least four different edge-case categories from the table above.
- Actually run at least five of them and record what truly happened — not what you assume happened.
- Mark each Pass or Fail honestly. A test case you wrote but did not run is a lie with formatting.
Reflect: which of your ten do you think the developers never considered? Did any of your five actually reveal strange behaviour?
Q1. A user types "banana" into an age field. Which edge-case category is that?
Reveal the answer
Wrong data type — text where a number is expected.
Q2. Two customers buy the last item in stock in the same second. What is that called?
Reveal the answer
A concurrency edge case. If handled badly, the shop oversells stock it does not have.
Q3. What goes in the "Expected Result" field of a test case?
Reveal the answer
What should happen if the software is working correctly — written before or independent of what actually happened.
Q4. Write one full test case, all five parts, for a checkout "Apply Coupon Code" field.
Reveal a model answer
TC-07 · Steps: Add an item to cart, go to checkout, enter an expired coupon code "XMAS2019", click Apply. · Expected: Coupon is rejected with a clear message such as "This code has expired"; order total is unchanged. · Actual: Discount applied and total reduced by 20%. · Status: FAIL. Full marks for structure; bonus marks because you tested an edge case rather than the happy path.
- I wrote 15 edge cases before touching AI
- I wrote 10 test cases and actually ran at least five
- At least one of my tests produced a surprising result