Module 03

Manual testing — the human eye on the product

Manual testing is a person deliberately using the software the way real users will — plus all the ways they shouldn't. It's where every tester starts, and where human judgement still beats any script.

What is manual testing?

Manual testing means executing test cases by hand — no scripts, no automation frameworks. The tester clicks, types, swipes, observes, and compares actual behavior to expected behavior.

Its superpower is judgement: a script can check that a button exists; only a human notices it's the wrong shade, overlaps the footer on a small phone, or that the whole flow just feels confusing.

Example Test case: "Checkout with an expired card".
Steps: add item → pay → enter card expiring 01/20.
Expected: clear error, cart preserved.
Actual: generic "Error 500", cart emptied. Two bugs
logged from one manual test.

When manual beats automation

  • Brand-new features that change daily — automation would break constantly.
  • Visual, layout and usability checks that need human perception.
  • One-off scenarios not worth the cost of scripting.
Illustration of a person hand-testing a mobile app with sticky notes and a clipboard

Types of manual testing — with examples

These are the types you'll actually be asked about in interviews and use on the job:

Exploratory testing

Unscripted investigation: learn, test and design cases simultaneously, following your instincts about where bugs hide.

ExampleIn a new chat feature, you try pasting a 10,000-character message, then emoji-only, then sending while offline.

Smoke testing

A fast pass over the critical paths of a new build: does it start, log in, and do its core job? If smoke fails, testing stops.

ExampleNew build arrives: open app → log in → add to cart → checkout. Fifteen minutes, go/no-go decision.

Sanity testing

A narrow check after a specific fix or small change: did the fix work, and did it obviously break its neighborhood?

ExampleDevs fixed the coupon bug — you retest coupons and the price summary next to them, nothing else.

Regression testing

Re-running existing tests after changes to confirm nothing that used to work is now broken. The prime candidate for automation later.

ExampleAfter a payments refactor, you re-run the full checkout suite: cards, wallets, refunds, receipts.

Usability testing

Watching whether real humans can actually use the thing — clarity, flow, frustration points, accessibility.

ExampleFive users try to cancel a subscription. Four can't find the option within two minutes. That's a finding.

User Acceptance Testing (UAT)

The final gate: business stakeholders or end users verify the software fits real-world needs before release.

ExampleThe client's accounting team runs a month-end close in the new system before signing off the go-live.

Strengths and limits

Strengths

  • Human judgement on look, feel and usability
  • No upfront scripting cost — start testing immediately
  • Flexible: adapts to changing features instantly
  • Finds the "weird" bugs scripts never look for

Limits

  • Slow and expensive to repeat at scale
  • Human error: fatigue misses defects
  • Poor fit for load/performance testing
  • Repetitive regression drains team morale

That's exactly where automation testing picks up — the next module.

Back: SDLC & STLC Next: Automation Testing