What is testing?
Testing is the practice of investigating software to find the gap between what it does and what it should do. You are not a bug-finder who runs scripts. You are an investigator who asks better questions than the people who built it.
“Testing is the infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.” — James Bach
Why testing matters
Software ships defects. Every time. Your job is to catch the ones that matter before a customer does. A good tester saves money, reputation, and sometimes lives. A great tester changes how the team thinks about quality.
The words you need
- Defect / bug — the product doesn't match the specification, the design, or user expectations.
- Test case — a specific scenario with inputs and an expected result. Learn how to write one →
- Test plan — what you will and won't test, and why.
- Regression — something that used to work, now doesn't.
- Smoke test — a quick pass to confirm the build is worth testing at all.
- Exploratory testing — simultaneous learning, test design, and execution.
- Happy path — the intended flow with valid data.
- Edge case — unusual but valid inputs at the boundaries.
- Severity — how bad the defect is.
- Priority — how urgently it should be fixed.
Where testing sits in the SDLC
Testing happens at every stage, not just “at the end”:
- Requirements — review specs. Ambiguity is a defect. This is called Shift-Left — testing before a single line of code is written.
- Design — review UX and architecture. Untestable design is a defect.
- Development — unit tests (devs) and component tests.
- Integration — pieces talking to each other.
- System — the whole product as a user sees it.
- UAT — business signs off on fit for purpose.
- Production — monitor, observe, learn.
The tester's mindset
- Be sceptical, not cynical. Assume it's broken until proven otherwise, but stay constructive.
- Ask “what if?” What if this field is empty? What if the network drops? What if the user speeds through?
- Read the specification, then test reality. They often disagree.
- Document what you see, not what you feel. Steps, inputs, expected, actual.
- Bugs are neutral. You're not attacking the developer. You're improving the product.
→ Deep dive: Testing Mindset learning module
What a good bug report looks like
- Title — “Login accepts empty password” beats “Login broken”
- Environment — browser, OS, build number, user role
- Steps to reproduce — numbered, exact, copy-pastable
- Expected result — what should happen
- Actual result — what did happen
- Evidence — screenshot, video, logs, network trace
- Severity & priority — your honest assessment
Ready?
Next: grad techniques → learning → your first practice page. Nothing you do here is graded — just get curious.