Manual Testing
The testing a script cannot do — structured exploration, and keeping regression coverage from swallowing the schedule.
What Automation Cannot See
Manual testing is not the cheap version of automation. It is the part that requires judgement: whether this feels wrong, whether the error message helps, whether a real person would give up here. Automation covers repetition; humans cover surprise.
Exploratory Testing
Exploratory testing is not clicking around. It is simultaneous learning, test design and execution: you form a theory about where the software is weak, probe it, and let what you find decide the next probe.
| Structure | What it does |
|---|---|
| Charter | A written mission: explore X using Y to discover Z |
| Time-box | 60–90 minutes, so it ends with findings rather than drifting |
| Session notes | What you tried, what you saw, what you did not get to |
| Debrief | Turns notes into bugs, new cases and areas to revisit |
Heuristics give a session traction. Follow the data through the system and back. Interrupt things — refresh mid-submit, hit back, lose the network, open two tabs. Push the boundaries the spec left vague: the empty state, the enormous input, the duplicate click, the stale session.
Regression Testing
Regression testing answers one question — did this change break something that used to work — and it is where manual effort quietly balloons. Every release adds cases; nobody removes any; eventually the suite cannot be run in the time available.
| Tactic | Effect |
|---|---|
| Risk-based selection | Test what changed and what depends on it, not everything |
| Automate the stable core | The cases that never change are the cheapest to hand over |
| Keep a smoke set | Ten minutes that decide whether a build is worth testing |
| Retire dead cases | A case for a removed feature is pure cost |
| Add a case per bug | The cheapest way to stop the same defect returning |
Automation earns its place here more than anywhere else: a regression pack is repetitive, well specified and run constantly — which is precisely what machines are good at and people are bad at. Reserve human time for the exploration that only a person can do.
Interview Questions
Why keep manual testing when you have automation?
Automated tests only assert what someone already anticipated. Judgement calls — is this confusing, does this error message help, would a real user give up — need a person.
What makes exploratory testing structured?
A charter stating what to explore and what to look for, a time-box, session notes, and a debrief that turns findings into bugs and new cases. Without those it is just clicking around.
How do you stop a regression suite becoming unrunnable?
Select by risk rather than running everything, automate the stable core, keep a short smoke set, retire cases for removed features, and add a case for each bug found.
Which tests are the best automation candidates?
Repetitive, well-specified, frequently run and stable — the regression core. Anything requiring judgement about feel or clarity stays with a person.
Where do the interesting bugs usually come from?
Combinations and interruptions: a valid action in an unusual order, a refresh mid-submit, two tabs, a lost connection, a stale session — states nobody designed for.
What goes in session notes?
What you tried, what happened, what looked suspicious, and what you did not get to. It makes an exploratory session reviewable and repeatable rather than personal knowledge.