Manual Testing Full Notes PDF For QA — Detailed Edition

Beginner to Interview-Ready | Manual Testing Part I & Part II

Manual Testing Notes for QA are designed to help beginners and experienced testers understand the fundamentals of software testing, including testing concepts, types of testing, test cases, test scenarios, bug reporting, defect life cycle, and real-time testing examples. These notes provide simple explanations, practical examples, and interview preparation topics to help QA testers build strong testing skills and prepare for real-world projects and software testing interviews.

Webvittha.com

PART I — Software Testing Fundamentals

Chapter 1: Long Forms and Important Terminology

A manual tester should understand common testing terms because they are used in requirements, meetings, test cases, defect reports, and interviews.

Important software testing terms

1. Error: A human mistake, such as a developer writing an incorrect calculation.
2. Defect or bug: A flaw in a requirement, design, code, or other work product that may cause incorrect behavior.
3. Failure: The observable incorrect behavior when software does not perform as expected.

Example:

• A developer writes price × quantity + tax when the requirement says tax must be calculated differently. This is an error in implementation.
• The incorrect formula exists in the application. This is a defect.
• The customer sees an incorrect total on the checkout page. This is a failure.

1. Test scenario: A high-level condition or feature to test.

• Example: Verify the login functionality.

1. Test case: Detailed steps to verify one particular behavior.

Example: Enter valid credentials, click Login, and verify that the dashboard opens.

1. Test data: The information used during testing, such as valid credentials, invalid passwords, product prices, or customer IDs.
2. Test environment: The setup in which testing occurs, including the application build, browser, device, database, and test accounts.
3. Test execution: Running test cases and recording whether actual results match expected results.
4. Test coverage: A measure of how much of the defined scope, requirements, code, or test conditions has been tested. The exact coverage measure depends on the context.

Interview question: What is the difference between a defect and a failure?

A defect is a flaw in the software or another work product. A failure is the observable incorrect behavior that may occur when that defect is triggered.

Chapter 2: SQA and Its Factors

2.1 What is Software Quality Assurance?

Software Quality Assurance (SQA) is the systematic set of activities used to ensure that software processes and deliverables follow agreed standards and quality requirements.

The main idea is to prevent defects where possible, rather than relying only on finding them after development.

For example, if a company repeatedly receives defects because requirements are unclear, SQA may introduce requirement reviews, coding standards, test reviews, and better development processes to prevent similar defects in future releases.

2.2 Objectives of SQA

• Ensure that requirements are complete, clear, and testable.
• Establish standards for development and testing.
• Reduce defects and rework.
• Improve reliability, security, and usability.
• Check compliance with relevant policies and standards.
• Make quality activities measurable and repeatable.
• Improve customer satisfaction.

2.3 Quality assurance vs. quality control vs. testing

These activities overlap in real organizations. For example, software testing is an important quality control activity, while QA may improve the process used to perform that testing.

2.4 Software quality factors

1. Functionality

The application provides the functions specified in its requirements.

Example: A registered customer can log in, search for a product, and place an order.

1. Reliability

The software performs consistently under specified conditions.

Example: A banking application completes normal transfers without unexpected crashes or duplicate transactions.

1. Usability

Users can learn and operate the application effectively.

Example: Users can find the checkout button and understand validation messages without confusion.

1. Performance efficiency

The application responds within acceptable time and resource limits.

Example: Product search returns results within the response-time target defined for the application.

1. Security

The system protects data and prevents unauthorized access.

Example: A customer cannot view another customer’s private order information by changing an order ID.

Other important factors include compatibility, accessibility, maintainability, portability, and recoverability.

2.5 What is the role of a manual tester in SQA?

A manual tester contributes to quality by:

1. Reviewing requirements and asking questions about unclear behavior.
2. Identifying missing scenarios before development is complete.
3. Preparing test scenarios, test cases, and test data.
4. Executing tests and documenting actual results.
5. Reporting reproducible defects.
6. Retesting fixes and performing regression testing.
7. Maintaining test evidence and status reports.
8. Sharing quality risks with developers, business analysts, and QA leads.

Interview answer: SQA is a process-oriented approach to preventing defects and improving quality, whereas testing checks software behavior to identify defects and failures.

Chapter 3: SDLC in Brief and Its Stages

3.1 What is SDLC?

The Software Development Life Cycle (SDLC) is a structured process used to develop, test, deploy, and maintain software.

The SDLC helps the team understand what must be built, how it will be built, who is responsible, and when the software can be released.

3.2 Stages of SDLC

01 Requirement Gathering and Analysis

The team understands customer needs, business rules, functional requirements, and non-functional requirements.

Tester’s responsibility: Review requirements, identify missing cases, and ask questions.

Example: A shopping website must allow users to search products, add products to the cart, and make payments.

02 Feasibility Study

The team evaluates whether the project is technically, financially, operationally, and legally feasible.

Tester’s responsibility: Identify test environment needs, technical constraints, and quality risks.

Example: Check whether the application must support older browsers or low-end mobile devices.

03 Software Design

Architects and designers plan system architecture, database structure, user interfaces, and component interactions.

Tester’s responsibility: Review designs and identify usability, integration, security, and testability concerns.

Example: Review the checkout design and identify what happens when payment fails.

04 Development or Coding

Developers implement the planned functionality and integrate software components.

Tester’s responsibility: Prepare test cases, test data, and test environments while development progresses.

Example: Developers build the login, product search, and shopping cart features.

05 Software Testing

The team evaluates the application against requirements and checks for defects.

Tester’s responsibility: Execute tests, record results, report defects, retest fixes, and assess regression risk.

Example: Verify whether a successful payment creates an order only once.

06 Deployment

The application is released to a production or other target environment.

Tester’s responsibility: Support release verification, smoke tests, and production-readiness checks as assigned.

Example: After deployment, confirm that the website opens and users can access critical functions.

07 Maintenance

The team fixes defects, supports users, improves features, and updates the software.

Tester’s responsibility: Test bug fixes, verify enhancements, and check existing features for regressions.

Example: After a payment gateway update, verify payment and order history.

3.3 Functional and non-functional requirements

Functional requirements describe what the application should do.

Examples:

• Users can log in.
• Users can reset passwords.
• Customers can add products to a cart.
• The system can generate invoices.

Non-functional requirements describe qualities and constraints on how the system operates.

Examples:

• The page should load within a defined response-time target.
• Only authorized users can access private information.
• The application should work on supported browsers.
• The system should recover appropriately after an interruption.

3.4 What is the tester’s role in SDLC?

Testing is not limited to the testing stage. Testers can contribute throughout the SDLC by reviewing requirements, discussing risks, preparing test cases, executing tests, and validating releases.

This is called early testing or shift-left testing when quality activities move earlier in the development process.

Interview question: Why is SDLC important?

SDLC provides a systematic way to manage requirements, design, development, testing, deployment, and maintenance. It improves coordination, visibility, and control over project quality, cost, and timelines.

Chapter 4: SDLC Models — Waterfall, V-Model, and Agile

An SDLC model defines how the stages of software development are organized and how work progresses between them.

4.1 Waterfall Model

The Waterfall model is a sequential development approach. A phase is generally completed and approved before the next phase begins.

Example: A project has stable requirements for a small internal application. The team completes requirements, design, development, and then formal testing.

Advantages

• Simple and easy to understand.
• Clear milestones and responsibilities.
• Documentation and approvals are emphasized.
• Can suit projects with stable requirements and predictable delivery.

Disadvantages

• Requirement changes can cause significant rework.
• Users may not see working software until later.
• Major problems may be discovered relatively late.
• Less flexible when business needs change frequently.

Tester’s role: Review requirements early, prepare the test plan and test cases, execute testing after receiving a suitable build, and validate defects.

4.2 V-Model

The V-Model is a development model that associates each major development stage with a corresponding testing level. Test planning and design are considered early, rather than waiting until coding is complete.

Example: While business requirements for an ATM are being defined, the team plans acceptance tests for withdrawals, balance inquiries, and transaction limits.

Advantages

• Encourages early test planning.
• Provides clear traceability between requirements and tests.
• Can work well in projects with stable requirements.
• Makes responsibilities and testing levels easier to define.

Disadvantages

• Changes can be costly.
• Less flexible for frequently changing requirements.
• Working software is not necessarily available early.

Important: Unit and integration testing may be performed by developers or dedicated test engineers, depending on the organization. A manual tester should understand the purpose of every level even if they do not execute every level.

4.3 Agile Model

Agile is an iterative and incremental approach to software development. Teams deliver small increments, gather feedback, and adapt to changing requirements.

A typical Agile sprint includes planning, development, testing, review, and retrospective activities.

Example: An e-commerce team first delivers login and product search, then shopping cart functionality, and later checkout and order tracking. Each increment is reviewed and tested.

Advantages

• Supports changing requirements.
• Encourages collaboration and frequent feedback.
• Allows earlier delivery of useful functionality.
• Testing can occur continuously throughout development.

Disadvantages

• Frequent changes can create regression risk.
• Poor coordination can cause incomplete requirements.
• Teams must communicate regularly.
• Scope and release dates require active management.

4.4 Waterfall vs. V-Model vs. Agile

4.5 Important Agile terminology

• Sprint: A fixed-length iteration during which a team works toward a goal.
• Product backlog: The ordered list of work desired for the product.
• Sprint backlog: The work selected for the sprint and the plan for delivering it.
• User story: A concise description of a user need.
• Acceptance criteria: Conditions that must be satisfied for a story to be accepted.
• Daily Scrum: A short event for the Scrum team to inspect progress and adapt its plan.
• Sprint review: An event to inspect the increment and gather feedback.
• Retrospective: A meeting to identify improvements to the team’s way of working.
• Definition of Done: The shared criteria that work must meet to be considered complete.

Example user story:

“As a registered customer, I want to reset my password so that I can regain access to my account.”

Acceptance criteria may include:

1. The user can request a reset using the registered email address.
2. The system displays an appropriate confirmation message.
3. The reset link expires according to the defined security policy.
4. The new password must satisfy the password requirements.

Interview question: How do you work as a manual tester in Agile?

I participate in requirement discussions and sprint planning, clarify acceptance criteria, prepare and execute test cases, report defects, retest fixes, perform regression testing, and communicate testing status during the sprint.

Chapter 5: Types of Testing in Detail

5.1 Sanity Testing

Definition: Sanity testing is a focused check of specific functionality after a change or fix to determine whether it works well enough for further testing.

Example: A developer fixes a coupon-code issue. The tester verifies that the coupon now applies correctly to an eligible order and checks the immediately related behavior.

When is it performed?

• After a small code change.
• After a defect fix.
• When a build contains a focused change that needs verification.

Advantages

• Quick feedback.
• Helps identify obvious problems early.
• Avoids spending time on extensive testing when the changed feature is clearly broken.

Limitations

• Does not provide comprehensive application coverage.
• Cannot guarantee that unrelated features are unaffected.

5.2 Black-Box Testing (BBT)

Black-box testing checks inputs and outputs without requiring knowledge of the internal implementation.

Example: A tester enters a valid password and verifies that login succeeds, without examining the source code.

Common techniques

Equivalence Partitioning (EP): Divide input data into groups expected to behave similarly.

Example: If the permitted age is 18–60 inclusive, the groups could be below 18, 18–60, and above 60. One or more representative values are selected from each group.

Boundary Value Analysis (BVA): Test values at and around the edges of an allowed range.

For the same age range:

• 17: below minimum
• 18: minimum
• 19: just above minimum
• 59: just below maximum
• 60: maximum
• 61: above maximum

Decision table testing: Test combinations of conditions and their expected outcomes.

Example: A discount may depend on membership status and minimum purchase amount.

State transition testing: Check how the system moves between states after an action.

Example: A user account may become temporarily locked after a configured number of failed login attempts.

Use-case testing: Test end-to-end user workflows.

Example: Search for a product, add it to the cart, pay, and verify order confirmation.

5.3 Functional Testing

Functional testing checks whether application features behave according to the specified requirements.

Examples:

• Login and logout
• Registration
• Search and filtering
• Add to cart and checkout
• Payment processing
• Password reset

How to perform functional testing

1. Understand the requirement.
2. Identify scenarios.
3. Prepare test data.
4. Write test cases and expected results.
5. Execute the tests.
6. Report mismatches.
7. Retest fixes and check related functionality.

5.4 System Testing

System testing verifies the complete integrated application against its specified requirements.

Example: For an e-commerce website, test registration, login, search, cart, checkout, payment, and order history as an integrated system.

It can include both functional and non-functional testing, depending on the scope.

5.5 Retesting

Retesting confirms whether a previously reported defect has been fixed.

Example:

1. The tester finds that a password reset link never opens.
2. A bug is reported with reproduction steps.
3. The developer fixes the issue.
4. The tester repeats the original failing test.
5. The tester records whether the issue still occurs.

Retesting should use the original failure conditions and any relevant additional conditions.

5.6 Regression Testing

Regression testing checks whether changes have unintentionally affected existing functionality.

Example: A change to checkout tax calculations may affect order totals, invoices, refunds, and order history. The tester identifies and checks related functionality based on risk.

Regression testing can be performed manually or with automation.

5.7 User Acceptance Testing (UAT)

UAT determines whether the application meets business needs and is acceptable for intended use.

Example: A business user validates that an employee leave-management system follows the approved leave policy and approval workflow.

UAT commonly checks:

• Business workflows.
• Acceptance criteria.
• User permissions.
• Business rules.
• Readiness for business use.

UAT is often performed by business users or designated acceptance testers, with QA support.

5.8 Ad-hoc Testing

Ad-hoc testing is informal testing without a predefined, detailed set of test cases.

Example: A tester explores an online registration form, tries unexpected inputs, refreshes the page, and navigates away to discover defects.

It is useful for discovering issues that were not anticipated in formal test cases, but results may be difficult to reproduce unless the tester records their actions.

5.9 Exploratory Testing

Exploratory testing combines learning, test design, and test execution.

Example: While testing a shopping cart, the tester explores quantity changes, removing items, switching accounts, session expiry, and navigation back to the cart.

A good exploratory test can use a test charter, which defines the feature, objective, and time limit.

Example charter: “Explore cart updates and totals for 30 minutes, focusing on quantity changes, item removal, and invalid quantities.”

Exploratory testing is more deliberate than simply clicking randomly. The tester records observations, evidence, and defects.

5.10 Monkey Testing

Monkey testing involves random or semi-random actions or inputs to discover crashes and unexpected behavior.

Example: Randomly tapping controls, opening and closing screens, and entering unusual values in a mobile application.

It may be manual or automated.

Difference from exploratory testing: Exploratory testing uses the tester’s learning and reasoning to guide the next action. Monkey testing emphasizes random or semi-random actions and can be especially useful for stability checks.

5.11 Severity and Priority

Severity is the impact of a defect on the application or user.

Priority is the urgency with which the defect should be fixed.

Severity levels often include:

• Critical: A major system failure or serious business/security impact.
• High: A major feature is unusable or significantly impaired.
• Medium: A feature is partly affected, often with a workaround.
• Low: A minor issue with limited impact.

Priority labels vary by company. Some use P0–P3, others use High/Medium/Low.

These are examples, not universal rules. Teams should classify defects using their agreed criteria.

Interview question: Can a low-severity defect have high priority?

Yes. For example, a spelling mistake in a high-visibility company logo or campaign banner may have low technical impact but high business urgency because the content is about to be published.

PART II — Testing Process and Documentation

Chapter 6: Software Testing Life Cycle (STLC)

6.1 What is STLC?

The Software Testing Life Cycle is a structured sequence of activities followed by a testing team to verify software quality.

SDLC covers the complete software development process, whereas STLC focuses specifically on testing activities.

6.2 Six major STLC phases

1 Requirement Analysis The QA team studies requirements, identifies testable features, and clarifies missing information.

Deliverables: Requirement questions, testable requirements, initial risk assessment.

2 Test Planning The QA lead or responsible tester defines scope, approach, resources, estimates, risks, and schedule.

Deliverables: Test plan, estimates, testing strategy.

3  Test Case Development Testers prepare scenarios, test cases, test data, and requirement traceability.

Deliverables: Test cases, test data, RTM.

4  Test Environment Setup The team prepares the application build, devices, browsers, test accounts, and required services.

Deliverables: Ready environment, environment checklist, smoke-test results.

5  Test Execution Testers execute cases, record results, report defects, retest fixes, and perform regression testing.

Deliverables: Execution results, defect reports, test status.

6  Test Cycle Closure The team evaluates coverage, defects, unresolved risks, and lessons learned.

Deliverables: Test summary report, metrics, closure notes.

6.3 Entry criteria and exit criteria

Entry criteria are the conditions that should be met before a testing activity begins.

Examples:

• Requirements are available.
• A testable build has been deployed.
• Test accounts and data are ready.
• The test environment is accessible.

Exit criteria are the conditions used to decide whether the testing activity can be considered complete.

Examples:

• Planned test cases have been executed or their status is documented.
• Critical defects are resolved or formally assessed.
• Required test coverage has been achieved.
• Remaining risks have been communicated.
• Test results are reviewed and approved by the appropriate people.

Entry and exit criteria depend on the project. Testing should not be declared successful merely because all test cases were executed; the results and unresolved risks also matter.

6.4 Example of STLC in a real project

Suppose a team is building a registration page.

1. Requirement analysis: Confirm required fields, password rules, and duplicate-account behavior.
2. Planning: Decide browsers, devices, scope, test estimates, and release risks.
3. Test case development: Prepare valid, invalid, boundary, and security-related scenarios.
4. Environment setup: Configure the test build, email service, and test accounts.
5. Execution: Register users, record results, and report defects.
6. Closure: Summarize passed and failed tests, defect status, and outstanding risks.

Interview question: What happens if requirements change during testing?

The tester assesses the impact, clarifies the updated behavior, updates affected test cases and test data, identifies regression scope, and communicates changes to the team.

Chapter 7: Test Plan

7.1 Definition

A test plan is a document that explains how a project, release, or feature will be tested.

It answers questions such as:

• What will be tested?
• What will not be tested?
• Who will perform the testing?
• Which environments and tools are needed?
• When will testing happen?
• What are the risks?
• How will completion be evaluated?

7.2 Components of a test plan

7.3 Example test plan for a login page

Project: E-commerce website login

Objective: Verify that registered users can log in securely and that invalid attempts are handled correctly.

Scope included:

• Login with valid credentials.
• Invalid username or password.
• Empty fields.
• Password masking.
• Forgot Password.
• Logout and session behavior.
• Login page usability on supported browsers.

Scope excluded: Payment processing and product recommendations, which will be tested separately.

Environment: Test website, supported browsers, test accounts, and test database.

Tools: Jira for defect tracking and a spreadsheet or test management system for test cases.

Risks: Test email service may be unavailable; test accounts may become locked; the build may be delayed.

Entry criteria: The login feature is deployed to the test environment and requirements are available.

Exit criteria: Planned login tests are completed or accounted for, important defects are assessed, and outstanding risks are documented.

7.4 Test strategy vs. test plan

A test strategy generally describes the higher-level testing approach, often across a project or organization. A test plan applies that approach to a particular project, release, or feature.

In some organizations, these are separate documents; in others, the strategy is included in the test plan.

Chapter 8: Test Case Preparation

8.1 What is a test case?

A test case is a documented set of preconditions, inputs, execution steps, and expected results used to check a specific behavior.

A good test case should be clear enough that another tester can execute it without guessing.

8.2 Components of a test case

8.3 Example: Complete login test case

TC_LOGIN_001

Functional

Title: Verify login with valid credentials.

Preconditions: The application is available and the user account is active.

Test data: A valid test username and password.

Steps:

1. Open the application login page.
2. Enter the valid username.
3. Enter the valid password.
4. Click the Login button.

Expected result: The application authenticates the user and opens the appropriate landing page.

Actual result: Record the observed behavior after execution.

Status: Not Run until the test is executed.

8.4 Types of test cases to write

For most features, think about several categories:

1. Positive: Valid inputs produce the correct result.
2. Negative: Invalid inputs are handled appropriately.
3. Boundary: Values at and around the limits are checked.
4. Validation: Required fields, formats, and constraints are enforced.
5. UI: Controls, labels, alignment, and visibility meet expectations.
6. Integration: Connected components exchange data correctly.
7. Security: Unauthorized access and inappropriate data exposure are prevented.
8. Compatibility: Supported browsers, devices, and operating systems behave correctly.
9. Error handling: Failures produce appropriate messages and recovery behavior.
10. Accessibility: Users can operate the feature using supported assistive technologies and input methods.

8.5 Test scenario vs. test case

Scenario: Verify the password reset feature.

Possible test cases:

• Submit a registered email address.
• Submit an unregistered email address.
• Submit an invalid email format.
• Submit an empty email field.
• Open an expired reset link.
• Use a reset link a second time.
• Enter a password that fails the password policy.
• Confirm whether the old password remains valid or is invalidated according to the requirements.

A single scenario can contain many test cases.

8.6 Test case writing best practices

• Use clear and concise language.
• Keep steps in the correct order.
• Define expected results precisely.
• Avoid combining unrelated checks into one test case.
• Use appropriate test data.
• Link test cases to requirements.
• Include positive, negative, and boundary conditions.
• Update test cases when requirements change.
• Keep sensitive test data out of reports and screenshots where possible.

Chapter 9: Test Case Review

9.1 Definition

A test case review is an evaluation of test cases to check whether they are accurate, complete, understandable, and aligned with requirements.

Reviews help identify problems before test execution.

9.2 Who reviews test cases?

• Peer testers
• QA leads or test managers
• Business analysts
• Product owners
• Developers, where technical input is useful

9.3 Test case review checklist

Before approving a test case, ask:

1. Is the requirement clearly identified?
2. Is the title meaningful?
3. Are the preconditions correct?
4. Is the test data appropriate?
5. Are the steps reproducible?
6. Is the expected result specific?
7. Are positive and negative cases included?
8. Have boundary values been considered?
9. Are important security and error-handling cases covered?
10. Are duplicate cases avoided?
11. Can the case be traced to a requirement?
12. Is the case feasible in the available test environment?

9.4 Practical example

Requirement: The password must contain at least eight characters.

An incomplete test case might only verify that Password123 is accepted.

A better set of test cases checks:

• Seven characters.
• Exactly eight characters.
• Nine characters.
• An empty password.
• Unsupported characters, if restrictions exist.
• Whether the application enforces any additional password rules.

The review also checks the expected behavior for each case against the actual requirement.

9.5 What happens after review?

The author corrects the identified issues, the reviewer confirms important changes, and the test cases are made ready for execution. Some teams record formal review comments and approval; others use a lighter peer-review process.

Chapter 10: Testing Documents

Documentation provides traceability, consistency, evidence, and communication throughout testing.

10.1 Important documents explained

1. BRD — Business Requirements Document

Describes the business problem, objectives, and desired outcomes.

Example: Customers must be able to order products online and receive order confirmation.

1. SRS — Software Requirements Specification

Describes detailed software requirements, including expected behavior and constraints.

Example: The system must display an order number after a successful checkout.

1. FRD — Functional Requirements Document

Describes what the system’s functions must do.

Example: The checkout page must calculate the order total using item prices, discounts, shipping, and applicable taxes.

1. Test plan

Describes the scope, resources, schedule, risks, and approach to testing.

1. Test scenarios

List the high-level features or conditions to test.

Example: Verify checkout functionality.

1. Test cases

Specify exact steps and expected results.

Example: Add a product to the cart, proceed to checkout, and verify the displayed total.

1. Test data

Contains the inputs required for execution.

Example: Valid account details, product IDs, coupon codes, and addresses.

1. RTM — Requirements Traceability Matrix

Maps requirements to test cases and helps identify coverage gaps.

Example:

1. Defect report

Documents a problem, including its title, environment, reproduction steps, expected result, actual result, severity, and supporting evidence.

1. Test execution report

Records which tests passed, failed, were blocked, or were not run.

1. Test summary report

Summarizes test completion, coverage, defect status, known risks, and the overall testing assessment.

10.2 Test summary example

Suppose a release has 100 planned test cases:

• 80 passed.
• 10 failed.
• 5 blocked.
• 5 not run.

The execution total is 100 cases. However, this does not mean testing is successful: the team must investigate the 10 failures, assess the blocked tests, and explain why 5 were not run.

A useful test summary communicates both the numbers and the release risks.

Chapter 11: Defect Life Cycle

11.1 What is a defect?

A defect is a flaw that causes software to behave differently from its specified or intended behavior.

Example: The requirement says that an invalid password must produce an error message, but the login page does nothing when an invalid password is submitted.

11.2 Defect life cycle stages

New / Reported

Assigned

Open / In Progress

Fixed

Ready for Retest

Verified / Closed

If retesting fails

Reopen the defect, add updated evidence, and return it for further investigation.

Status names and transitions differ between teams and defect management tools.

11.3 Defect status explanations

• New / Reported: The tester creates a defect report.
• Assigned: The defect is assigned to a responsible developer or team.
• Open / In Progress: The defect is being investigated or fixed.
• Fixed: The developer reports that a correction has been made.
• Ready for Retest: The fix is available in a testable build.
• Retest: QA repeats the failing scenario.
• Reopened: The problem still occurs or the fix is incomplete.
• Closed: The defect has been verified and accepted as resolved.
• Rejected / Not a Bug: The behavior is considered correct or the report is invalid.
• Duplicate: The issue has already been reported.
• Deferred: The team postpones the fix.
• Cannot Reproduce: The team cannot reproduce the reported behavior with the available information.

11.4 How to report a good defect

A good defect report should contain:

• A clear title.
• Application version and environment.
• Exact steps to reproduce.
• Expected result.
• Actual result.
• Reproducibility or frequency, if known.
• Severity and priority according to team criteria.
• Screenshot, recording, logs, or other evidence where appropriate.

Example

Title: Login button does not respond after valid credentials are entered.

• Preconditions: Active test account exists.
• Steps: Open login page, enter valid credentials, click Login.
• Expected result: User is authenticated and redirected to the correct page.
• Actual result: The button does not trigger login.
• Evidence: Screen recording and relevant browser console details, if available.
• Severity and priority: Assigned based on impact, scope, and urgency.

11.5 Defect life cycle interview question

Q: What do you do if a developer says the defect is not reproducible?

Answer: I verify the steps, environment, test data, and application version. I try to reproduce the issue again, provide clear evidence such as screenshots, recordings, or relevant logs, and discuss the result with the developer. If it still cannot be reproduced, I document the findings and follow the team’s defect process.

PART III — Real-Time Practical Test Cases

These practical exercises are important because interviewers often ask, “How will you test this application or real-world object?” They want to see whether you can identify normal behavior, invalid conditions, boundaries, failures, and usability issues.

For every test case below, the actual expected result should follow the relevant requirements or product specifications.

Chapter 12: Traffic Signal Testing

12.1 Objective

Verify that the traffic signal displays the correct indications, follows the configured sequence, and handles failures safely.

12.2 Detailed test cases

12.3 Additional scenarios

• Rain, fog, and other visibility conditions.
• Power restoration after an interruption.
• Communication loss between the controller and monitoring system.
• Incorrect timing configuration.
• Damaged or obscured signal indications.
• Pedestrian crossing timing.
• Coordination between adjacent intersections.

Interview tip: Explain how you would test the signal’s functional behavior and safety requirements. Do not assume a universal timing sequence; use the approved traffic-system specifications.

Chapter 13: Keyboard Testing

13.1 Objective

Verify that the keyboard detects supported key presses accurately, handles combinations correctly, and works reliably with the target computer or device.

13.2 Detailed test cases

13.3 Negative testing

A tester may also check:

• A key that does not respond.
• A key that produces repeated characters unexpectedly.
• Wireless interference.
• Low battery in a wireless keyboard.
• Unsupported key combinations.
• Incorrect keyboard layout settings.

Interview tip: If you are testing a physical keyboard, check hardware behavior. If you are testing an on-screen keyboard, also check touch response, layout changes, accessibility, and display behavior.

Chapter 14: WhatsApp Testing

14.1 Objective

Verify that users can register, communicate, share supported media, manage chats, and control privacy settings correctly.

14.2 Detailed test cases

14.3 Negative and edge cases

• Attempt to send a message with no network connection.
• Attempt to share an unsupported or oversized file.
• Deny camera or microphone permissions.
• Attempt to open an expired verification code.
• Test a very long message.
• Test a group action without the required permissions.
• Test the application when device storage is nearly full.
• Test notification behavior when notifications are disabled.

14.4 Example defect

Title: Send button remains disabled after a valid text message is entered.

• Steps: Open a conversation, type a message, observe the send button.
• Expected result: The send control becomes available according to the app’s rules.
• Actual result: The control remains disabled.
• Evidence: Screen recording and device/app details.

Chapter 15: Facebook Testing

15.1 Objective

Verify that users can authenticate, publish content, interact with posts, manage relationships, and control their privacy settings.

15.2 Detailed test cases

15.3 Additional testing

• Invalid post content or unsupported media.
• Very long posts and comments.
• Upload interruption.
• Privacy setting changes.
• Notifications when permissions are disabled.
• Session expiration.
• Unauthorized attempts to access private content.
• Browser back-button behavior after logout.

Important: For social media applications, privacy and access-control testing are especially important. Verify that content is visible only to the intended audience.

Chapter 16: ATM Testing

16.1 Objective

Verify that an ATM processes supported banking transactions accurately, securely, and reliably.

ATM testing is high risk because defects can affect money, accounts, card security, and transaction records. Tests must use a controlled environment and authorized test cards or accounts.

16.2 Detailed test cases

16.3 Detailed example: Cash withdrawal

Preconditions

• A valid test card is available.
• The test account is active.
• The account has sufficient funds.
• The ATM has sufficient cash.
• The banking test environment is working.

Steps

1. Insert the test card.
2. Enter the correct PIN.
3. Select Cash Withdrawal.
4. Select the eligible account.
5. Enter a valid amount.
6. Confirm the transaction.
7. Observe the dispenser and screen.
8. Verify the transaction record and remaining balance in the authorized test system.

Expected result: The correct amount is dispensed, the account is debited once, the transaction is recorded correctly, and the card/session is handled according to the design.

16.4 Important ATM edge cases

• Network disconnects after the account is debited but before cash is dispensed.
• Cash is dispensed but the confirmation message is delayed.
• Power fails during a transaction.
• The user abandons the session.
• The ATM runs out of receipt paper.
• The card is not collected within the permitted time.
• A withdrawal request is repeated due to a timeout.

For these cases, the expected behavior must be defined by banking transaction rules. The tester must verify that the customer is not incorrectly charged, that transaction records remain consistent, and that recovery or reversal procedures work correctly.

Chapter 17: Water Bottle Testing

17.1 Objective

Verify that a water bottle meets its product specifications for capacity, sealing, usability, durability, and materials.

17.2 Detailed test cases

17.3 Example: Leakage testing

1. Inspect the bottle and lid for visible damage.
2. Fill the bottle to the specified level.
3. Close the lid according to instructions.
4. Place it on a clean, dry surface.
5. Invert it under the approved test conditions.
6. Observe the bottle for the specified duration.
7. Record any leakage and compare it with acceptance criteria.

Expected result: Leakage remains within the defined acceptance criteria.

Unlike website testing, physical-product testing requires defined test equipment, environmental conditions, and measurable acceptance criteria.

Chapter 18: Mobile Phone Testing

18.1 Objective

Verify that the phone’s hardware, operating system, connectivity, applications, and user interface operate according to specifications.

18.2 Detailed test cases

18.3 Important edge cases

• Incoming call while another application is active.
• Network loss during a download.
• Battery critically low during a task.
• Storage becomes full while recording a video.
• Application is interrupted and resumed.
• Device switches between Wi-Fi and mobile data.
• Permission is revoked while an app is running.
• Device heats up during a defined workload.
• Application is updated while the device has limited connectivity.

Interview tip: Mobile testing covers functional behavior, device compatibility, connectivity, interruptions, performance, security, and usability. Always specify which device models and operating-system versions are supported.

Chapter 19: Pen Testing

Here, “pen” means a physical writing pen, not penetration testing.

19.1 Objective

Verify that the pen writes consistently, meets its design specifications, and remains usable under normal conditions.

19.2 Detailed test cases