Learning Objectives
By the end of this lesson, you'll be able to:
- 🎯 Define functional testing and explain what it verifies
- 📋 Translate a requirement into functional test cases
- 🔄 Apply the input → process → output model to any feature
- 🧪 Design tests for happy paths, negative paths, boundary values, and error handling
The Big Idea
The most fundamental question in software testing: does it do what it's supposed to do?
Not does it look right. Not does it load fast. Not is it secure.
Does the software behave according to its specification?
This is functional testing — and it's the foundation of everything else you'll do as a QA tester.
What Is Functional Testing?
Functional testing verifies that software works in accordance with its specified requirements.
The source of truth: requirements documents, user stories, and acceptance criteria. If the spec says "when the user enters an invalid email, an error message 'Please enter a valid email address' appears" — your functional test checks exactly that.
The core model: Input → Process → Output
Every functional test follows this structure:
- Input: What you give the system (user action, data entry, API call)
- Process: What the system does with it (validation, calculation, database write)
- Output: What you observe (message displayed, page navigated, record created)
If the actual output matches the expected output, the test passes. If it doesn't, you've found a bug.
The Four Types of Functional Test Cases
1. Happy Path
The main successful scenario — the way things should work when everything is correct.
Example (login form):
- Input: valid email + correct password
- Expected output: user is logged in, redirected to dashboard
2. Negative Path
What happens when the input is wrong, missing, or unexpected.
Example (login form):
- Input: valid email + wrong password
- Expected output: error message "Incorrect password. Please try again."
- Input: empty email field
- Expected output: error message "Email is required."
3. Boundary Value Analysis
Testing the edges of valid input ranges, where bugs love to hide.
Example (age validation — must be 18–99):
- Input: 17 → Expected: rejected ❌
- Input: 18 → Expected: accepted ✅
- Input: 99 → Expected: accepted ✅
- Input: 100 → Expected: rejected ❌
4. Error Handling
What happens when something goes wrong that the user didn't cause — like a server error or network timeout.
Example:
- Server returns 500 during login
- Expected: friendly error message, not a blank screen or raw error dump
Requirements as Your Test Spec
Requirements are test cases waiting to be written. Every "shall" and "must" in a spec is a test waiting to happen.
Requirement: "The system shall reject passwords shorter than 8 characters and display the message 'Password must be at least 8 characters long.'"
Resulting test cases:
- Enter a 7-character password → expect rejection with exact message
- Enter an 8-character password → expect acceptance
- Enter a 0-character password (empty) → expect rejection with message (or "required" message)
If there's no requirement document, use the user story's acceptance criteria. If there's no acceptance criteria, ask. Testing without a specification is guessing.
Real-World Example
Feature: "Add to Cart" button on a product page
| Test Case | Input | Expected Output |
|---|---|---|
| Happy path | Click "Add to Cart" for available item | Item appears in cart, cart count increments by 1 |
| Out of stock | Click button for out-of-stock item | Button disabled OR "Out of stock" message |
| Zero quantity | Change quantity to 0, click button | Error: "Quantity must be at least 1" |
| Max quantity | Enter 9999, click button | Either accepted or "Maximum X items" error |
| Not logged in | Click button without being logged in | Redirect to login OR item added to guest cart |
Pro Tips
💡 Always test both what should work AND what should fail. Beginners focus on happy paths. Experienced testers know negative paths are where the most bugs hide.
💡 Read the requirement before writing the test. It sounds obvious, but many testers test based on what they think the feature should do, not what the spec says it should do. These can be different.
💡 When there's no spec, make one. If a feature has no written requirements, document your assumptions in a test plan before testing. This protects you ("I tested per these assumptions") and helps the team discover gaps.
Summary
- 📋 Functional testing verifies behavior against requirements
- 🔄 Core model: Input → Process → Output — expected vs. actual
- 🧪 Four test case types: happy path, negative path, boundary value, error handling
- 📖 Source of truth: requirements, user stories, acceptance criteria
- 🚫 Without a spec, you're guessing — make sure you have one
Up next: Lesson 3.2 — Non-functional Testing: the "how does it work?" to complement our "does it work?" ⚡