What is Quality in Manual Testing?
In manual testing, quality does not simply mean “no bugs.” It’s a broader concept. Quality is the degree to which a software product meets the stated and implied needs of its users when it is used under specified conditions.
In simpler terms, a high-quality software is:
- Fit for its purpose: It does what it’s supposed to do.
- Meets user expectations: It provides a good experience, not just basic functionality.
Breaking Down Quality with Examples: The “Ice Cream Cone” Model
Imagine a user wants to buy an ice cream cone from a shop. Let’s see how different levels of quality apply.
1. Functional Quality: “Does it work?”
This is the most basic level. Does the software perform its intended functions correctly?
- Example: The user pays for a chocolate ice cream cone.
- Low Quality: The server gives them an empty cone. Or the payment system crashes. The core function fails.
- High Quality: The user correctly receives a chocolate ice cream cone. The core function works.
2. Non-Functional Quality: “How well does it work?”
This is where user experience (UX) comes into play. The function works, but is it a good experience?
- Reliability:
- Low Quality: The ice cream cone breaks immediately, spilling ice cream everywhere. (The software crashes under normal use).
- High Quality: The cone is sturdy and holds the ice cream reliably.
- Usability (Ease of Use):
- Low Quality: The ice cream is scooped into the cone upside down, making it messy to eat. The menu is confusing and hard to read. (The software is clunky and illogical).
- High Quality: The ice cream is neatly presented. The menu is clear. It’s easy and intuitive to order.
- Performance:
- Low Quality: The user has to wait 10 minutes in line while the server struggles to scoop the ice cream. (The software is slow and sluggish).
- High Quality: The user is served quickly and efficiently.
- Compatibility:
- Low Quality: The shop only accepts cash, but the user only has a card. (The software only works on one specific browser or device).
- High Quality: The shop accepts cash, card, and mobile pay. (The software works across different browsers, devices, and operating systems).
- Security:
- Low Quality: The cashier writes down the user’s credit card number on a piece of paper for everyone to see. (The software has vulnerabilities that leak user data).
- High Quality: The payment is processed securely through an encrypted system.
3. Perceived Quality: “How does it feel?”
This is the emotional response the product generates.
- Example:
- Low Quality: The ice cream is served in a dirty, chipped bowl. The server is rude. (The software has a poor, outdated design with spelling mistakes).
- High Quality: The ice cream is served in a nice wafer cone with a chocolate flake on top. The shop is clean, and the server is friendly. (The software has a beautiful, modern UI with smooth animations and a helpful tone). The user feels good about their purchase.
The Manual Tester’s Role in Ensuring Quality
A manual tester’s job is to verify all these aspects of quality.
- For Functional Quality: They execute test cases to ensure “the chocolate ice cream is indeed chocolate and is given to the user.”
- For Non-Functional Quality: They explore the software to ask: “Is it easy to find the ‘order’ button? Does the page load quickly? Does it look right on my phone?”
- For Perceived Quality: They provide feedback like: “This error message is harsh and confusing. The color scheme is unpleasant. This workflow feels frustrating.”
Conclusion: Finding a bug where the software crashes (functional quality) is crucial. But a great manual tester also identifies issues that lead to a poor user experience (non-functional and perceived quality). True quality is achieved when the software not only works correctly but is also a pleasure to use.
What is a Defect in Manual Testing?
In manual testing, a defect (also called a bug or fault) is any imperfection, flaw, or deviation in the software application that causes it to behave in an unintended, unexpected, or incorrect way compared to its requirements or expected behavior.
The core idea is a variance between the actual result and the expected result.
4 Detailed Examples of Defects
Here are four common types of defects a manual tester might find, ranging from simple to complex.
Example 1: Functional Defect (Calculation Error)
- Scenario: Testing a calculator app.
- Expected Result: When a user enters
5 + 5and presses=, the result should be10. - Actual Result: The app displays
55. - The Defect: The “+” button is concatenating the numbers (behaving like a string operator) instead of performing mathematical addition. This is a clear functional failure.
Example 2: User Interface (UI) Defect
- Scenario: Testing an e-commerce website’s product page on a mobile phone.
- Expected Result: The “Add to Cart” button should be fully visible and clickable without needing to scroll sideways.
- Actual Result: The “Add to Cart” button is cut off on the right side of the screen, and the user cannot click it.
- The Defect: This is a UI or layout bug. The page is not responsive for a specific mobile screen size, directly preventing the user from making a purchase.
Example 3: Content Defect
- Scenario: Testing a banking application’s fund transfer confirmation screen.
- Expected Result: The confirmation message should be professional, clear, and free of spelling errors, e.g., “Your transfer of $100 to John Doe was successful.”
- Actual Result: The message says, “Your transfer of $100 to John Doe was sucessful.” (misspelling of “successful”).
- The Defect: This is a content or cosmetic bug. While it doesn’t break functionality, it looks unprofessional and can erode user trust in the application’s attention to detail.
Example 4: Logical / Workflow Defect
- Scenario: Testing a user registration flow.
- Expected Result: After successfully filling out a form and clicking “Submit,” the user should receive a “Registration Successful!” message and be logged into their new account.
- Actual Result: The user gets a “Registration Successful!” message but is then redirected back to the login page instead of being logged in automatically.
- The Defect: This is a logical or workflow bug. The individual steps work (form validation, saving data, showing message), but the overall sequence of events is incorrect and creates a poor user experience.
What a Tester Does Upon Finding a Defect:
A manual tester doesn’t just find the defect; they report it systematically. A good defect report includes:
- Title: A short, clear summary (e.g., “Add to Cart button not visible on iPhone 12 screen”).
- Description: Detailed explanation of the issue.
- Steps to Reproduce: Exact steps to make the defect appear consistently.
- Expected vs. Actual Result: As shown in the examples above.
- Evidence: A screenshot or screen recording.
- Severity & Priority: How bad the bug is and how quickly it needs to be fixed.
Finding these defects early is the primary goal of manual testing, as it saves the company time, money, and protects its reputation.