Manual Testing Introduction
What manual testing is, when it beats automation, and how to write clear test scenarios and test cases.
What is manual testing?
Manual testing means a person exercises the software — clicking, typing, comparing results with expectations — without automation scripts. It's the foundation of every QA career: before you can automate a test, you have to know what a good test is.
Manual testing isn't "the old way". Even teams with thousands of automated checks rely on people to:
- Test new features that are still changing daily.
- Judge usability: is this confusing, slow or ugly?
- Do exploratory testing, where the next test depends on what you just saw.
- Check things that are expensive to automate and rarely run.
Test scenario vs test case
A test scenario is a one-line description of what to test:
Verify a registered user can log in with valid credentials.
A test case is the detailed, repeatable how: preconditions, steps, data and expected result. One scenario usually becomes several test cases.
Anatomy of a good test case
| Field | Example |
|---|---|
| ID | TC-LOGIN-003 |
| Title | Login fails with a wrong password and shows an error |
| Priority | High |
| Preconditions | User ayesha@example.com exists with password Secret#2026 |
| Test data | Email ayesha@example.com, password wrong-pass |
| Steps | 1. Open /login 2. Enter the email 3. Enter the password 4. Click Log in |
| Expected result | User stays on /login; message "These credentials do not match our records." is shown; password field is cleared |
| Actual result | (filled during execution) |
| Status | Pass / Fail / Blocked |
Rules that make test cases useful
- One purpose per test case. "Login works and profile updates" is two test cases.
- Specific expected results. "Error shown" is weak; quote the exact message and where it appears.
- Independent. Each test sets up its own preconditions instead of relying on the previous one.
- Reusable data. Put test data in the case so anyone can run it.
- Written for someone else. A new teammate should be able to execute it without asking you.
Positive and negative tests
For every feature, write both:
- Positive tests — valid input, the happy path works.
- Negative tests — invalid input, the system fails gracefully.
For a login form:
Positive
TC-01 Valid email + valid password → dashboard
TC-02 Email with uppercase letters (AYESHA@EXAMPLE.COM) → dashboard
Negative
TC-03 Wrong password → error, stays on login
TC-04 Unregistered email → same generic error (no "user not found" leak)
TC-05 Empty fields → "Email is required" / "Password is required"
TC-06 Email without @ → "Enter a valid email address"
TC-07 6 wrong attempts → temporarily locked, message shown
TC-08 SQL in email field (' OR 1=1 --) → treated as text, error shown
Notice TC-04 and TC-08: good testers think about security and privacy, not just features.
Where test cases live
Small teams use spreadsheets; most teams use a test management tool such as TestRail, Zephyr or Xray (Jira), qTest or Azure Test Plans. These tools organise cases into suites, record each run's results, and link failures to bug tickets — which makes reporting much easier.
A simple manual testing workflow
- Read the story and acceptance criteria; ask questions about gaps.
- Write scenarios, then test cases using test design techniques.
- Get them reviewed by a developer or another tester.
- Execute on the test environment and record results.
- Raise clear bug reports for failures.
- Retest fixes and run the relevant regression tests.
The next lesson covers the techniques that tell you which inputs are worth testing.