Manual Testing Basics

What is Manual Testing?

Manual Testing is the process of testing software by hand, without the use of automation tools. A tester acts as an end user and manually executes test cases to identify defects, verify behaviour, and ensure the software meets its requirements.

Despite the rise of automation, manual testing remains a critical skill. It is particularly valuable for exploratory testing, usability evaluation, and any scenario where human judgement is required to determine pass or fail.

Types of Manual Testing

Manual testing covers a wide range of testing types. Here are the most important ones every tester should know.

Functional Testing

Validates that each function of the software works as specified in the requirements. The tester provides input, executes actions, and verifies that the output matches the expected result.

• Login / logout flows
• Form validation (required fields, error messages)
• CRUD operations (Create, Read, Update, Delete)
• API response validation

Regression Testing

After a bug fix or new feature is added, regression testing ensures that existing functionality has not broken. It re-executes previously passing test cases to catch unintended side effects.

Regression testing is often the best candidate for automation — but manual regression is still needed when the test suite is not yet automated or when changes are complex.

Exploratory Testing

Exploratory testing is simultaneous learning, test design, and test execution. The tester explores the application without predefined test cases, using experience and intuition to discover unexpected defects.

When to use it

• When requirements are incomplete or unclear
• When you want to simulate real user behaviour
• When you need to understand a new feature quickly
• As a complement to scripted testing

User Acceptance Testing (UAT)

UAT is performed by the end client or business stakeholders — not the QA team — to validate that the software meets their business needs. The QA team's role is to support UAT by preparing test data, environments, and documentation.

Types of UAT

• Alpha Testing — Done by internal users at the development site
• Beta Testing — Done by real end users in a production-like environment

Smoke Testing & Sanity Testing

These are quick, lightweight testing types that act as gatekeepers before deeper testing begins.

How to Write Effective Test Cases

A well-written test case leaves no room for ambiguity. Here is the standard format used across the industry:

Tips for writing good test cases

• Write test cases for both positive (happy path) and negative (invalid input) scenarios
• Keep steps atomic — one action per step
• Be specific with expected results — avoid vague statements like "it should work"
• Cover boundary values (e.g., minimum/maximum input lengths)
• Peer-review test cases before the testing phase begins

Pros & Cons of Manual Testing

Bug Reporting Best Practices

A defect report is only as useful as the information it contains. A vague bug report wastes developer time and delays fixes. Here is what every good bug report must include:

Severity vs Priority

These two terms are often confused but mean different things:

• Severity — The technical impact of the bug. A crash is always high severity.
• Priority — How urgently it needs to be fixed. A crash on a rarely-used screen may be lower priority than a UI bug on the checkout flow.

A typo on the homepage may be low severity but high priority (visible to every visitor). A crash in an admin-only debug panel may be high severity but low priority.

Manual Testing Checklist

Before signing off any manual test cycle, run through this checklist. It's the same one I use across projects:

• ✅ All test cases in scope have been executed
• ✅ All critical and high-severity defects are resolved or formally accepted as known issues
• ✅ Regression tests run on the final build after last defect fix
• ✅ Negative test cases covered (invalid inputs, empty fields, boundary values)
• ✅ Cross-browser or cross-device testing completed per scope
• ✅ All defects logged with full reproduction steps, environment, and screenshots
• ✅ Test cases updated to reflect any requirement changes during the cycle
• ✅ RTM updated — every requirement has at least one test case
• ✅ Test execution report prepared and shared with stakeholders
• ✅ Test environment details documented for reproducibility

Common Manual Testing Mistakes

These are the mistakes I see most often — especially from testers earlier in their careers:

• Testing only the happy path. If you only test what should work, you are missing half the job. Always add negative test cases: what happens with empty input, invalid characters, network timeouts, or maximum field lengths?
• Logging vague bugs. "The page doesn't load" tells a developer almost nothing. Every bug report needs exact steps, environment details, and the actual error. If a developer can't reproduce it from your report alone, the report failed.
• Not retesting after a fix. Closing a defect without retesting it on the actual fixed build is one of the most common mistakes. A developer marking something as "fixed" is not the same as QA verifying it is fixed.
• Ignoring non-functional requirements. Performance, accessibility, and security are requirements too. A form that accepts an SQL injection string is a bug, even if the UI looks correct.
• No test data preparation. Starting test execution with no test data prepared means improvising during the cycle — leading to inconsistent results and missed edge cases. Prepare representative test data before the cycle begins.

Writing Effective Test Cases

A test case is only as useful as the clarity it provides to whoever executes it — whether that is you next sprint, a new team member, or an auditor reviewing a release. Effective test cases leave no room for interpretation.

The Anatomy of a Good Test Case

Every well-written test case contains seven fields. None of them are optional:

• Test ID — A unique identifier, typically in the format TC_MODULE_001. This lets you reference the test case in bug reports and traceability matrices without ambiguity.
• Title — A concise, action-oriented summary of what the test validates. "Login with valid credentials" is a title. "Test login" is not.
• Preconditions — Everything that must be true before step 1 is executed. User account must exist, app must be installed, test data must be seeded. A missing precondition is the most common reason a test case cannot be reproduced.
• Test Steps — Numbered, atomic steps. One action per step. "Enter email, enter password, click login" is three steps, not one.
• Expected Result — Precisely what should happen. This is the field where most test cases fail. "Page loads" is not an expected result. "HTTP 200 returned within 2 seconds and the user is redirected to /dashboard" is.
• Actual Result — Filled in at execution time. What actually happened. If the test passes, this matches the expected result exactly.
• Status — Pass, Fail, Blocked, or Skipped. A test that cannot be executed due to a dependency or environment issue should be marked Blocked — not left blank.

Positive vs Negative Test Cases

Positive test cases verify the happy path — the system works correctly when given valid input. Negative test cases verify the system handles invalid, unexpected, or boundary input gracefully. Most teams write three to four positive tests for every negative test. The ratio should be closer to one to one. Login with a valid account is important — but so is login with an empty password, a deactivated account, SQL injection in the email field, and a password that is 257 characters long. Defects hide in the negative cases that nobody wrote.

Peer Review Checklist for Test Cases

Before a test case is approved for a test cycle, a second QA engineer should review it against this checklist:

• Does the title clearly state what is being validated — not just what action is being taken?
• Are all preconditions listed, including test data, environment state, and user permissions?
• Is each step genuinely atomic — one action only, with no compound steps hidden behind "and"?
• Is the expected result specific and measurable — no vague language like "works correctly" or "page loads"?
• Is there at least one corresponding negative test case for each positive test case?
• Are boundary values covered — minimum, maximum, and one beyond maximum?
• Is the test case linked to the requirement or user story it validates in the RTM?
• Could someone who has never seen the feature execute this test case without asking any questions?

Test Case Maintenance

A test case written once is rarely valid forever. Updates are triggered by: a requirement change that alters expected behaviour, a bug that reveals the original expected result was wrong, a new browser or OS version added to the supported matrix, a UI change that makes existing steps inaccurate, or a change in test data that invalidates preconditions. Stale test cases that no longer reflect the actual application produce misleading pass results — which is more dangerous than no test case at all.

Good vs Poor Test Cases — Side by Side