Manual Testing Tutorial

Chapter 5: Test Case Development

5.1 What is a Test Case?

A Test Case is a detailed document that outlines a specific set of actions to verify whether a particular functionality or
feature of the software behaves as expected. It includes inputs, execution steps, expected results, and any necessary
configurations to perform the test.

5.2 Components of a Test Case

A well-structured test case includes several key components:

1. Test Case ID: A unique identifier for the test case (e.g., TC_001).

2. Test Case Title: A brief description of the test case.

3. Preconditions: Any setup or conditions that must be met before executing the test (e.g., user must be logged
in).

4. Test Steps: The detailed steps to perform the test.

5. Test Data: The input values used in the test (e.g., username, password).

6. Expected Result: The anticipated result or behavior after executing the test steps.

7. Actual Result: The actual outcome observed after executing the test case.

8. Pass/Fail: Indicates whether the test passed or failed based on the expected and actual results.

9. Priority: The importance level of the test (e.g., High, Medium, Low).

10. Remarks: Additional comments or observations related to the test.

5.3 Writing Effective Test Cases

Writing effective test cases is a critical skill in manual testing. Here are some guidelines for creating clear and efficient
test cases:

 Be Clear and Concise: Test cases should be easy to understand. Avoid ambiguous or unclear language.

 Use Simple and Relevant Data: Use realistic data in test cases that simulate real-world usage.

 Cover Different Scenarios: Include positive and negative scenarios to ensure thorough testing (e.g., valid and
invalid inputs).

 Maintain Consistency: Follow a consistent format for all test cases to ensure clarity and ease of execution.

5.4 Example Test Case Template

 Test Case ID : TC_001

Test Case Title : Login with valid credentials

Preconditions : User is on the login page

Test Steps :

1. Enter a valid username in the username field

2. Enter a valid password in the password field

3. Click the "Login" button

Test Data : Username: user1, Password: password123

Expected Result : The user should be redirected to the homepage.

Actual Result : (To be filled after execution)

Pass/Fail : (To be filled after execution)

Priority : High

Remarks : None

5.5 Example Test Cases

1. Test Case 1: Valid Login

o Test Case ID: TC_002

o Test Case Title: Login with valid credentials

o Preconditions: User is on the login page

o Test Steps:

1. Enter a valid username (e.g., "user1") in the username field.

2. Enter a valid password (e.g., "password123") in the password field.

3. Click the "Login" button.

o Test Data: Username: user1, Password: password123

o Expected Result: User should be redirected to the homepage.

o Actual Result: (To be filled after execution)

o Pass/Fail: (To be filled after execution)

o Priority: High

o Remarks: None

2. Test Case 2: Invalid Login

o Test Case ID: TC_003

o Test Case Title: Login with invalid credentials

o Preconditions: User is on the login page

o Test Steps:
 1. Enter an invalid username (e.g., "wronguser") in the username field.

2. Enter an incorrect password (e.g., "wrongpassword") in the password field.

3. Click the "Login" button.

o Test Data: Username: wronguser, Password: wrongpassword

o Expected Result: An error message should appear stating "Invalid username or password."

o Actual Result: (To be filled after execution)

o Pass/Fail: (To be filled after execution)

o Priority: High

o Remarks: None

5.6 Types of Test Cases

1. Positive Test Cases:

o Test scenarios where the application is expected to behave correctly.

o Example: Logging in with valid credentials.

2. Negative Test Cases:

o Test scenarios where the application should handle invalid input or errors gracefully.

o Example: Logging in with an incorrect password.

3. Boundary Test Cases:

o Focus on the boundaries or edge cases of input values.

o Example: Testing a password field with the maximum allowed characters.

4. Integration Test Cases:

o Test cases that validate the interaction between multiple components.

o Example: Verifying that a user can add an item to the cart and proceed to checkout.

5.7 Real-Time Example: Testing an E-commerce Application

Test Case: Add Item to Cart

 Test Case ID: TC_004

 Test Case Title: Add item to shopping cart

 Preconditions: User is logged in and on the product listing page

 Test Steps:

1. Browse through the product listing and select a product.

2. Click on "Add to Cart" button.

3. Navigate to the cart page.

4. Verify that the selected product appears in the cart.

  Test Data: Product: Laptop (Price: $999)

 Expected Result: The selected product should be added to the cart with the correct price and quantity.

 Actual Result: (To be filled after execution)

 Pass/Fail: (To be filled after execution)

 Priority: High

 Remarks: None

5.8 Key Considerations for Test Case Development

 Clarity: The steps and expected results must be easy to understand.

 Reusability: Test cases should be reusable for future testing.

 Traceability: Test cases should map back to requirements or user stories to ensure full coverage.

 Maintainability: Test cases should be easy to maintain and update as the software evolves.

Chapter 6: Test Plan

6.1 What is a Test Plan?

A Test Plan is a comprehensive document that outlines the strategy, scope, approach, resources, and schedule for
testing activities. It defines the testing objectives, deliverables, and the criteria for testing success, ensuring that all
aspects of the software are tested effectively.

6.2 Importance of a Test Plan

A Test Plan is essential for:

 Guiding the Testing Process: It provides a clear roadmap for the testing process.

 Ensuring Consistency: Ensures all team members follow the same approach and understand the scope of
testing.

 Resource Allocation: Helps in planning the required resources, tools, and time for testing.

 Risk Management: Identifies potential risks and outlines mitigation strategies.

 Communication Tool: Serves as a reference for the team, stakeholders, and clients.

6.3 Components of a Test Plan

A well-structured Test Plan includes the following key components:

1. Test Plan ID: A unique identifier for the test plan.

2. Introduction: A brief overview of the testing objectives and goals.

3. Test Items: The software components or features that will be tested.

 4. Scope of Testing: Defines what is included and excluded from testing.

5. Test Strategy: The overall approach to testing, including methodologies and levels of testing.

6. Test Deliverables: The documents and artifacts that will be produced during the testing process.

7. Testing Resources: A list of tools, environments, and team members required for testing.

8. Test Schedule: A timeline outlining the milestones and deadlines for testing activities.

9. Entry and Exit Criteria: Defines the conditions that must be met to begin and conclude testing.

10. Risk and Mitigation Plan: Identifies potential risks in the testing process and strategies for mitigating them.

11. Approval and Sign-off: The process for obtaining approval of the test plan and its components.

6.4 Test Plan Example Structure

1. Test Plan ID : TP_001

2. Introduction : Overview of the test plan for testing the e-commerce platform

3. Test Items : Login functionality, Shopping cart, Checkout process

4. Scope of Testing :

- In-scope: Test login, product search, cart, and checkout features

- Out-of-scope: Payment gateway, mobile app testing

5. Test Strategy :

- Functional Testing: Valid and invalid login scenarios

- Regression Testing: Ensure new code does not break existing features

6. Test Deliverables : Test cases, Test execution reports, Defect logs, Test summary report

7. Testing Resources : Selenium for automation, JIRA for defect tracking

8. Test Schedule :

- Test Execution: 5th Jan - 15th Jan

- Test Closure: 16th Jan

9. Entry and Exit Criteria:

- Entry: Test environment set up, test cases prepared

- Exit: All test cases executed, all defects closed or deferred

10. Risk and Mitigation :

- Risk: Limited test environment availability

- Mitigation: Coordinate with DevOps team for timely setup

11. Approval and Sign-off: Product Manager, QA Lead

6.5 Key Considerations for Test Plan Development

1. Clarity and Detail: A test plan should be clear and detailed enough for anyone to understand the testing
approach.
 2. Scope: The scope must be carefully defined to avoid scope creep and to ensure the testing process is focused.

3. Realistic Scheduling: The timeline should be feasible, considering resource availability and the complexity of
the testing.

4. Resource Allocation: Properly allocate tools, environments, and team members based on expertise and
availability.

5. Risk Management: Identify potential risks (e.g., resource constraints, environment issues) and plan mitigation
strategies.

6. Approval Process: Ensure proper sign-offs and approvals from stakeholders to proceed with the testing phase.

6.6 Real-Time Example: Test Plan for an E-commerce Platform

Test Plan ID: TP_001

Introduction:
This test plan defines the approach and activities for testing the e-commerce platform’s key features, including user
login, product search, shopping cart functionality, and checkout process.

Test Items:

 Login: Verify login functionality with valid and invalid credentials.

 Shopping Cart: Test adding/removing items, cart persistence, and price calculation.

 Checkout: Ensure smooth checkout process, including shipping options and order confirmation.

Scope of Testing:

 In-scope: Functional testing of login, cart, and checkout; Regression testing for any changes in the cart
functionality.

 Out-of-scope: Payment gateway integration, mobile app testing.

Test Strategy:

 Functional Testing: Test cases for login, search, cart, and checkout.

 Regression Testing: Ensure that the checkout process and cart functionality work after new updates.

Test Deliverables:

 Test cases for each scenario.

 Test execution report with results for each test case.

 Defect logs and test summary report at the end of the testing phase.

Testing Resources:

 Tools: Selenium for automation (if applicable), JIRA for defect tracking.

 Team: 2 QA testers, 1 test lead, 1 automation engineer.

Test Schedule:

 Test Execution: January 5th to January 15th.

 Test Closure: January 16th.

Entry and Exit Criteria:

 Entry Criteria: Test environment setup, test cases prepared, and test data in place.
  Exit Criteria: All planned tests executed, critical defects resolved, test summary prepared.

Risk and Mitigation:

 Risk: Limited availability of test data.

 Mitigation: Coordinate with the business team to prepare realistic test data in advance.

Approval and Sign-off:

 Approvers: Product Manager, QA Lead

6.7 Key Benefits of a Test Plan

 Efficiency: Streamlines the testing process by providing a clear roadmap.

 Quality Assurance: Helps ensure that all critical aspects of the software are tested thoroughly.

 Stakeholder Alignment: Ensures all stakeholders are aligned on the testing approach, timeline, and
deliverables.

 Risk Mitigation: Identifies potential risks early on and prepares strategies to minimize their impact.

6.8 Conclusion

The Test Plan is a crucial document in manual testing. It ensures that testing is structured, organized, and aligned with
project goals. By defining the scope, resources, timelines, and risk management strategies, it provides a clear
framework for conducting effective testing.