Manual Testing
Beginner 10 min read Manual Testing

Testing Fundamentals

Testing verifies that a system behaves as specified and surfaces defects before users do. Learn the V-model, the difference between verification and validation, the core testing principles, and how to turn a requirement into a test case.

verificationvalidationV-modeltest levelstest principlestest case
Introduction

What is this?

Software testing is the process of evaluating a system against its requirements and finding defects before release. It spans static analysis (reviews and inspections), dynamic execution of test cases, and both functional and non-functional checks. Testing cannot prove the absence of defects, but it reduces risk and builds confidence in a release.

Motivation

Why do you need it?

  • A defect found early is dramatically cheaper to fix — a requirements-phase defect can cost 10 to 100 times less than one found in production.
  • Testing verifies that requirements were implemented correctly and validates that the right product was built for the user.
  • It protects revenue and reputation by stopping defects from reaching real users.
  • Well-documented tests act as a living specification that new team members and maintainers can rely on.
  • Regression testing keeps existing features working while new features and refactors land.
Think about it

Mental model

Imagine

A restaurant food taster

Think of

A tester

The taster verifies every dish against the recipe before it reaches customers, and can describe the problem precisely enough for the kitchen to fix it. A tester verifies software against requirements and reports defects with enough detail for a developer to act.

Mechanics

How it works

  • Analyze requirements and specification documents to understand expected behavior.
  • Design test cases that cover valid, invalid and boundary inputs, with concrete expected results.
  • Set up the test environment with the right hardware, OS, browsers and test data.
  • Execute the test cases and record the actual results next to the expected results.
  • Report discrepancies as defects, then re-test the fixes and run regression to confirm nothing else broke.

The V-model maps each development phase to a corresponding test level.

Requirements analysis
Design phases
Implementation
System testing
Acceptance testing
Reference

Key commands

curl -I https://staging.example.com/login

Verify the login page is reachable before testing begins.

HTTP/1.1 200 OK
curl -s https://staging.example.com/healthz

Check the application health endpoint for a clean start state.

{"status":"ok"}
git describe --tags --always

Record the exact build under test so results stay traceable.

v2.0-RC1-3-g1a2b3c4
npx playwright --version

Confirm browser tooling is installed in the test environment.

1.49.0
git log --oneline -5

Review recent commits that changed the build under test.

Hands-on

Examples

Turning a requirement into a test case

Turning a requirement into a test case
Test Case ID : TC-LOGIN-001
Priority     : High
Precondition : An account exists for alice@example.com
Steps:
  1. Navigate to the login page
  2. Enter username "alice@example.com"
  3. Enter password "S3cure!Pass"
  4. Click "Sign In"
Expected Result: Dashboard loads and greeting shows "Welcome, Alice"
Actual Result  : Dashboard loads successfully
Status         : PASS

Each test case records an ID, priority, precondition, concrete steps and expected result. Expected and actual results are recorded side by side so outcomes are comparable and repeatable, and a PASS/FAIL status makes the case countable for reports.

Real world

In production

  • Release gates require manual smoke and exploratory passes to succeed before any deploy.
  • Manual regression cycles run before every major release to catch integration regressions automation misses.
  • New features are manually verified across the browsers and devices the automation suite does not cover.
  • User acceptance testing is always manual — real users validate end-to-end workflows that matter to the business.
Guidelines

Best practices

  • Test early: shift testing left into requirements and design phases instead of waiting for code.
  • Separate test data, test environment and execution records so results stay reproducible.
  • Write test cases before the code is ready for the feature (a test-first mindset).
  • Include negative and boundary scenarios, not just the happy path.
  • Log the exact build, environment and data set used for every run.
Watch out

Common mistakes

  • Testing only the happy path and missing error and edge-case behavior.
  • Assuming your understanding of the requirements — always ask when anything is ambiguous.
  • Running tests on a shared environment with dirty data and calling the results valid.
  • Reporting defects without the steps, environment and expected-vs-actual detail a developer needs.
Root cause analysis

Common issues

Error
Test fails intermittently
Root cause

Flaky timing or shared mutable test data in the environment

Fix

Run the test in isolation, reset data per run, and check for timing-dependent assertions.

Error
Cannot log into the test environment
Root cause

Credentials changed or SSO policy blocks access

Fix

Check with the environment owner, rotate credentials, and document the current login flow.

Error
Test passes but the user still reports a bug
Root cause

The test case did not cover the real user scenario

Fix

Pair with the reporter to understand the exact path and add a test for it.

When things break

Debugging tips

  • Reproduce a defect in the cleanest environment you can before reporting it.
  • Capture screenshots, logs and network traffic at the exact moment of failure.
  • Check whether the defect reproduces across browsers or devices to narrow its scope.
  • Verify a fix against the exact steps that produced the original failure, not a variant of them.
Interviews

Interview checkpoint

Practice

Hands-on lab

Verify a Login Page with Scripted Test Cases
30 min · beginner
In progress
Objectives
  • Prepare and health-check the test environment
  • Write test cases covering positive, negative and boundary scenarios
  • Execute the cases and record actual vs expected results
  • Report a defect with reproduction evidence

Verify a Login Page with Scripted Test Cases

30 min · beginner

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which term describes checking that the product was built correctly according to the specification?

2

Testing can prove that a software system is free of defects.

3

A login form accepts an empty password and signs the user in. Which testing approach would most likely have caught this?

Quick reference

Cheat sheet

Core vocabulary
VerificationAre we building the product right?
ValidationAre we building the right product?
RegressionRetest old features after changes
Test caseSteps, data, expected result
DefectActual result differs from expected
Smoke testCritical paths, run first
Go deeper

Official documentation

ISTQB — Certified Tester Foundation Level (CTFL) v4.0
docs
ISTQB — International Software Testing Qualifications Board
docs
Guru99 — Software Testing Tutorial
docs
Ministry of Testing
docs