1. Scenario: A system accepts a password with a length requirement between 8 and 20 characters (both inclusive).

The system validates that the password meets this length requirement. Question: Design test cases using Boundary
Value Analysis to validate the password length.? (5)

Answer:

Boundary Value Analysis (BVA) focuses on testing the boundary values around a specified range—in this case, the
password length requirement of 8 to 20 characters. Here are five test cases using BVA:

1. Test Case 1: Test with a password length of 7 characters (boundary just below the minimum).

Expected Result : The system should reject the password as it does not meet the minimum length requirement.

2. Test Case 2: Test with a password length of 8 characters (boundary at the minimum).

Expected Result : The system should accept the password as it meets the minimum length requirement.

3. Test Case 3: Test with a password length of 20 characters (boundary at the maximum).

Expected Result : The system should accept the password as it meets the maximum length requirement.

4. Test Case 4 : Test with a password length of 21 characters(boundary just above the maximum).

Expected Result : The system should reject the password as it exceeds the maximum length requirement.

5. Test Case 5 : Test with a password length of 9 characters(just above the minimum boundary).

Expected Result : The system should accept the password as it meets the length requirement within the specified
range.

2. Scenario: A university application system requires applicants to have between 0 and 40 credits to qualify for a
certain program. Question: Using equivalence partitioning, Create test cases.(5)

Answer:

Equivalence Partitioning (EP) divides input data into partitions (valid and invalid) to reduce the number of test cases
while ensuring good coverage. For the university application system where applicants need between 0 and 40
credits, we can create the following test cases:

1. Test Case 1 : Test with -1 credits (invalid partition: less than the minimum).

Expected Result : The system should reject the application as credits are below the minimum requirement.
2. Test Case 2 : Test with 0 credits(valid partition: minimum boundary).

Expected Result : The system should accept the application as it meets the minimum credit requirement.

3. Test Case 3 : Test with 20 credits(valid partition: within range).

Expected Result : The system should accept the application as it is within the specified credit range.

4. Test Case 4 : Test with 40 credits (valid partition: maximum boundary).

Expected Result : The system should accept the application as it meets the maximum credit requirement.

5. Test Case 5 : Test with 41 credits (invalid partition: above the maximum).

Expected Result : The system should reject the application as it exceeds the maximum credit requirement.

3. Scenario: A loan approval system accepts loan applications based on the following conditions:(5)

• Age: The applicant must be at least 18 years old.

• Credit Score: The applicant must have a credit score of 700 or higher.

• Income: The applicant must have an income of at least $30,000 per year.

The system decides to approve or reject the loan based on these conditions.

Question: Create a decision table to test the loan approval system

Answer:

Here’s a decision table for the loan approval system, based on the conditions provided:

| Test Case | Age >= 18 | Credit Score >= 700 | Income >= $30,000 | Expected Result |

|-----------|-----------|---------------------|--------------------|------------------|

|1 | No | No | No | Reject |

|2 | No | No | Yes | Reject |

|3 | No | Yes | No | Reject |

|4 | No | Yes | Yes | Reject |

|5 | Yes | No | No | Reject |

|6 | Yes | No | Yes | Reject |

|7 | Yes | Yes | No | Reject |

|8 | Yes | Yes | Yes | Approve |

Explanation of the Decision Table:

Test Cases 1–4: The applicant is under 18, which automatically leads to rejection, regardless of other factors.

Test Cases 5–7: The applicant is 18 or older but fails one or more of the other criteria (credit score or income),
resulting in rejection.

Test Case 8: The applicant meets all criteria (age, credit score, and income), resulting in loan approval.

This decision table effectively covers all possible combinations of the conditions for loan approval.

4.Scenario: Consider an online shopping cart system that can transition between the following states: Empty, Has
Items & Checked Out.

The events that trigger state transitions are: Add Item, Remove Item & Checkout.

Question: Use state transition and Identify test cases using State Transition Testing for this shopping cart system.(5)

Answer:

For the online shopping cart system with states **Empty**, **Has Items**, and **Checked Out**, and events
**Add Item**, **Remove Item**, and **Checkout**, we can design the following test cases using State Transition
Testing:

| Test Case | Initial State | Event | Final State | Expected Result |

|-----------|---------------|---------------|---------------|--------------------------------------------------|

|1 | Empty | Add Item | Has Items | Item added successfully, cart has items. |

|2 | Empty | Remove Item | Empty | Cart remains empty (no items to remove). |

|3 | Has Items | Add Item | Has Items | Item added successfully, cart still has items. |

|4 | Has Items | Remove Item | Empty | Item removed, cart is now empty. |

|5 | Has Items | Checkout | Checked Out | Cart is checked out successfully. |

|6 | Checked Out | Add Item | Checked Out | No transition; cart remains checked out. |

|7 | Checked Out | Remove Item | Checked Out | No transition; cart remains checked out. |

|8 | Checked Out | Checkout | Checked Out | No transition; cart remains checked out. |

1. Test Case 1: From an empty cart, adding an item moves it to Has Items.
2. Test Case 2: Attempting to remove an item from an empty cart leaves it in Empty (no transition).

3. Test Case 3: Adding an item to a cart that already has items keeps it in Has Items.

4. Test Case 4: Removing the last item from a cart with items moves it to Empty.

5. Test Case 5: Checking out a cart with items transitions it to Checked Out.

6-8. Test Cases 6–8: Once the cart is in Checked Out, no further actions (adding/removing items or additional
checkout attempts) should change the state.

These test cases cover all state transitions for the shopping cart system based on the given events.

5.Choose a simple software application or website.(5)

• Brief Objectives and Scope of the Application.

• Write a test plan outlining how you would test this application.

• Develop at least 3 Scenarios and 5 test cases for functional testing of the application.

• Identify potential non-functional tests you would perform

Answer:

Chosen Application: Online To-Do List Application

Objectives and Scope of the Application

The Online To-Do List Application is designed to help users organize and manage tasks efficiently. It allows users to
create, edit, delete, and mark tasks as complete or incomplete. The application is accessible from both desktop and
mobile browsers.

Scope:

- Task Management: Create, update, delete, and mark tasks as complete.

- Task Organization: View tasks by status (completed, pending) and sort by due date.

- User Account Management: User registration, login, and logout functionality.

Test Plan

Objective : Verify that the Online To-Do List Application’s core functions (task management, sorting, account
management) operate as intended, ensuring a smooth user experience.

Test Types:

1. Functional Testing: Verify functionality of creating, updating, deleting, and managing tasks.

2. Non-Functional Testing: Test for performance, usability, compatibility, and security.

Test Environment:

Devices: Desktop (Windows, macOS), Mobile (iOS, Android).

Browsers: Chrome, Firefox, Safari, and Edge.

Tools: Selenium for automated testing, manual testing for usability.

Functional Testing Scenarios and Test Cases

Scenario 1: User Account Management

Test Case 1: Verify that users can successfully register with valid details.

Test Case 2: Verify that users can log in with a registered email and password.

Test Case 3: Verify that an error message appears when users attempt to log in with incorrect credentials.

Test Case 4: Verify that users can successfully log out of their account.

Test Case 5: Verify that password reset functionality works correctly, sending a reset link to the registered email.

Scenario 2: Task Creation and Management

Test Case 1: Verify that a user can create a new task with a title and due date.

Test Case 2: Verify that users can edit a task’s title, description, and due date.

Test Case 3: Verify that users can delete a task and that it no longer appears in the task list.

Test Case 4: Verify that users can mark a task as complete and that it appears in the "Completed" list.

Test Case 5: Verify that a user cannot create a task without a title, displaying an error message.

Scenario 3: Task Sorting and Filtering

- Test Case 1: Verify that users can filter tasks by status (All, Pending, Completed).

- Test Case 2: Verify that tasks can be sorted by due date in ascending and descending order.

- Test Case 3: Verify that filtering by status updates the task list accordingly.

- Test Case 4: Verify that when a task is marked as complete, it automatically moves to the "Completed" list.

- Test Case 5: Verify that tasks are displayed chronologically based on their due dates in the list.

Non-Functional Testing

1. Performance Testing:

- Verify the app loads tasks in under 2 seconds under normal load.

- Stress test by adding a high volume of tasks (e.g., 500+ tasks) to ensure performance is acceptable.

2. Usability Testing:

- Assess the ease of navigation for task management (add, edit, delete).

- Verify accessibility standards (color contrast, keyboard navigation, screen reader support).

3. Compatibility Testing:

- Verify functionality across various browsers (Chrome, Firefox, Safari, Edge).

 - Test responsiveness on different devices (desktop, tablet, mobile).

4. Security Testing:

- Test for secure login and logout processes.

- Check password reset link expiration and validation.

- Ensure that unauthorized users cannot access another user’s tasks.

This test plan provides comprehensive functional and non-functional testing coverage to ensure the Online To-Do
List Application is reliable, user-friendly, and secure.