CHAPTER 04
Intermediate
Manual Testing Fundamentals
Updated: May 16, 2026
25 min read
# CHAPTER 4
Manual Testing Fundamentals
1. Introduction
Despite the rise of automation, Manual Testing remains the foundational pillar of Software Quality Assurance. An automated script can only check exactly what it is programmed to check; it cannot determine if a UI design looks confusing to a human, nor can it intuitively explore an application to find edge-case vulnerabilities. Manual testing requires a human brain, deep domain knowledge, and intense analytical thinking. In this chapter, we will master the mechanics of Manual Testing. We will learn how to design high-level Test Scenarios, write granular, step-by-step Test Cases, and execute unscripted Exploratory Testing.2. Learning Objectives
By the end of this chapter, you will be able to:- Understand the enduring importance of Manual Testing in modern QA.
- Differentiate between a Test Scenario and a Test Case.
- Write a professional, execution-ready Test Case with clear steps and expected results.
- Understand the concept and value of Exploratory Testing.
- Create basic QA documentation and execution logs.
3. Test Scenarios vs. Test Cases
These are the two main documents a Manual Tester creates.- Test Scenario: A high-level description of *what* needs to be tested. It is usually a single sentence.
- *Example:* "Verify the Login Functionality."
- Test Case: A detailed, step-by-step instruction manual on *how* to test a specific aspect of the scenario. A single scenario will have multiple test cases.
- *Example Case 1:* "Verify Login with Valid Credentials."
- *Example Case 2:* "Verify Login with Invalid Password."
- *Example Case 3:* "Verify Login with Blank Fields."
4. Anatomy of a Professional Test Case
A well-written Test Case can be handed to a brand-new employee, and they should be able to execute it without asking any questions. It contains:-
1.
Test Case ID: Unique identifier (e.g.,
TC_LOGIN_001).
- 2. Title/Description: What is being tested.
- 3. Pre-conditions: What must be true before starting (e.g., "User must have a registered account in the database").
- 4. Test Steps: Exact actions to take (e.g., "1. Go to /login. 2. Enter email. 3. Click Submit").
-
5.
Test Data: The specific data to use (e.g.,
email: test@example.com).
- 6. Expected Result: What the system *should* do (e.g., "User is redirected to the Dashboard").
- 7. Actual Result: What the system *actually* did (Filled in during execution).
- 8. Status: Pass, Fail, or Blocked.
5. Exploratory Testing
Test Cases are "Scripted Testing." Exploratory Testing is unscripted.- The Concept: The tester uses their experience, intuition, and creativity to explore the application dynamically, actively looking for edge cases that the formal test cases missed.
- The Value: Formal test cases follow the "Happy Path" and expected "Sad Paths." Exploratory testing finds the bizarre bugs (e.g., "What happens if I upload a PDF into the profile picture field while simultaneously disconnecting my WiFi?").
6. Positive vs. Negative Testing
- Positive Testing: Testing with valid data to ensure the application does what it is supposed to do. (e.g., Logging in with the correct password).
- Negative Testing: Testing with invalid data to ensure the application handles errors gracefully and does not crash. (e.g., Trying to buy an item with -5 quantity). Negative testing finds the most bugs.
7. Visual Learning: Test Case Table
| Test Case ID | Title | Pre-Condition | Test Steps | Expected Result | Actual Result | Status |
|---|---|---|---|---|---|---|
TC_AUTH_01 | Valid Login | User account exists | 1.Navigate to /login 2.Enter valid email 3.Enter valid password 4.Click 'Login' | User is redirected to Dashboard | (Left blank until execution) | (Blank) |
8. Best Practices
- Atomic Test Cases: A test case should validate exactly ONE thing. Do not write a single test case that says "Create account, login, add item to cart, and checkout." If it fails, you won't know which step broke. Break it into 4 separate test cases.
9. Common Mistakes
- Ambiguous Steps: Writing a step that says "Enter data and submit." What data? Submit where? Test cases must be completely unambiguous. Say: "Enter 'admin@test.com' into the Email Input Field and click the blue 'Log In' button."
10. Mini Project: Write Test Cases
Scenario: You are testing a simple "Search Bar" on an E-Commerce site. Your Task: Write 3 Test Scenarios/Cases.- 1. Positive Case: Search for an exact product name that exists (e.g., "iPhone 15"). *Expected:* The exact product is displayed.
- 2. Negative Case: Search for a string of random characters (e.g., "xyz123"). *Expected:* A "No products found" message is displayed; the site does not crash.
- 3. Edge Case: Click the "Search" button with a completely blank search field. *Expected:* An error prompts the user to enter a term, or it returns the default product list.
11. Practice Exercises
- 1. Explain why Exploratory Testing is necessary even if an application has 1,000 highly detailed, scripted Test Cases.
- 2. Create a professional Test Case table (ID, Title, Steps, Expected Result) for a "Forgot Password" feature.
12. MCQs with Answers
Question 1
What is the fundamental difference between a Test Scenario and a Test Case?
Question 2
Entering !@#$%^&*() into an email field to see if the application handles the error without crashing is an example of:
13. Interview Questions
- Q: A developer argues that Manual Testing is dead and everything should be automated. As a QA Engineer, how do you defend the absolute necessity of Manual and Exploratory Testing?
- Q: Walk me through the anatomy of a professional Test Case. Why is defining the "Pre-condition" absolutely critical?
- Q: Give me three examples of "Negative Testing" you would perform on a Credit Card Payment form.