Project 1 - V&V SW Analysis - I
Write a Test plan to test features of a new mobile phone (Blackbox test) that needs to be implemented based on the following requirements. (The product is still in the development stage and is yet to be UA (User Acceptance ) tested. Every other thing to be included in the test plan can be hypothetical.
Ans:
US-1:As a Product owner, when long pressed the power button of the phone shall switch on with a company logo at the center of the screen.
Test Plan for Power Button Functionality and Company Logo Display
Objective:
To thoroughly test the power button functionality of the new mobile phone and ensure that, when long-pressed, the device switches on and displays the company logo at the center of the screen as specified in the requirement.
Testing Environment:
- Mobile phone prototype under development
- Testing device or emulator
- Testers' devices for manual testing
- Testing documentation and tracking tool
Test Approach:
- Black-box testing: Focuses on testing the external behavior without knowledge of internal code or logic.
- Manual testing: Initial testing stages will be performed manually by testers.
- Automated testing: Consider automating the tests using appropriate tools in later stages.
Test Cases:
Test Case 1: Power Button Long Press - Normal Scenario
Description: Verify that the power button responds correctly to a long press and that the device powers on with the company logo displayed.
Test Steps:
- Press and hold the power button for 3 seconds or longer.
- Observe the device's response.
Expected Result: The device should power on, and the company logo should be displayed at the center of the screen.
Test Case 2: Power Button Long Press - Edge Case (Minimum Duration)
Description: Verify that a long press of minimal duration doesn't trigger the power on.
Test Steps:
- Press and hold the power button for slightly less than the required duration.
- Observe the device's response.
Expected Result: The device should not power on; no company logo should be displayed.
Test Case 3: Power Button Long Press - Edge Case (Excessive Duration)
Description: Verify that a very long press doesn't have adverse effects on the device.
Test Steps:
- Press and hold the power button for a significantly longer duration.
- Observe the device's response.
Expected Result: The device should not become unresponsive or display unexpected behavior.
Test Case 4: Company Logo Display - Power On Sequence
Description: Verify that the company logo is displayed at the center of the screen during the boot-up sequence.
Test Steps:
- Power on the device using the power button.
- Observe the screen during boot-up.
Expected Result: The company logo should be displayed prominently at the center of the screen as the device boots up.
Test Execution:
- Manually execute the test cases on the testing device or emulator.
- Document the test results, including observations, deviations, and defects.
Defect Reporting:
- Report any deviations from the expected behavior, including the power button not responding, incorrect logo display, or any unexpected behavior.
Test Automation (Hypothetical):
- Automation can be considered for regression testing in later stages of development.
- Tools like Appium or Espresso could be used for automating UI interactions and verifying logo display.
Conclusion:
This test plan outlines the manual black-box testing procedures for verifying the power button functionality and company logo display on the new mobile phone. By following this plan, you ensure that the specified requirements are met before proceeding to User Acceptance Testing (UA).
US- 2: As a Customer,when the power button is pressed my phone is switched ON and all my icons of the APPS shall be present in the grid
Test Plan for Power Button Functionality and App Icons Display
Objective:
To test the power button functionality of the mobile phone and ensure that when the power button is pressed, the device switches on and all app icons are present in the grid.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- List of all installed apps for verification
Test Approach:
- Blackbox testing
- Manual testing for initial stages
Test Cases:
Test Case 1: Power Button Press and App Icons Display
Description: Verify that the device powers on and all app icons are present in the grid after pressing the power button.
Test Steps:
- Power off the device (if not already).
- Press the power button to switch on the device.
- Wait for the device to boot up and display the home screen.
- Observe the presence of all app icons in the grid.
Expected Result: The device should power on, and all app icons should be displayed in the grid on the home screen.
Test Execution:
- Perform manual testing for the initial implementation.
- Execute the test case on the testing device or emulator.
Defect Reporting:
- If the device does not power on or if any app icons are missing from the home screen, report the issue with detailed steps and observations.
Conclusion:
This test plan outlines the manual testing procedure for verifying the power button functionality and the presence of all app icons in the grid on the home screen. By following this plan, you can ensure that the specified requirements are met before User Acceptance Testing (UA).
US- 3: As a Product owner,when the phone is powered ON ,I shall see the "call the phone" icon as the first icon at the bottom bar of my screen.
Test Plan for "Call the Phone" Icon Placement
Objective:
To test the correct placement of the "call the phone" icon as the first icon on the bottom bar of the screen when the mobile phone is powered on.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- TestBench Extreme (TBExtreme) for test automation (for automated testing)
Test Approach:
- Blackbox testing
- Manual testing for initial stages
- Automated testing using TBExtreme for regression testing
Test Cases:
Test Case 1: "Call the Phone" Icon Placement
Description: Verify that the "call the phone" icon is correctly placed as the first icon on the bottom bar of the screen upon powering on the device.
Test Steps:
- Power on the mobile phone.
- Observe the bottom bar of the screen.
Expected Result: The "call the phone" icon should be visibly and correctly positioned as the first icon on the bottom bar of the screen.
Test Execution:
- Perform manual testing for the initial implementation.
- Create and execute automated test scripts using TBExtreme for regression testing once the functionality stabilizes.
Defect Reporting:
- If the "call the phone" icon is not correctly placed as the first icon on the bottom bar, report the issue with detailed steps and observations.
Test Automation Using TBExtreme:
- TBExtreme is a test automation tool that can help streamline regression testing.
- Write test scripts using TBExtreme's scripting language to simulate device power-on and verify icon placement.
- Automate the test cases and schedule them for regular execution during the development cycle.
Conclusion:
This test plan outlines the manual testing procedures and provides an overview of how to automate the testing process using TBExtreme. By following this plan, you can ensure that the "call the phone" icon is correctly positioned on the bottom bar of the screen as per the specified requirement before User Acceptance Testing (UA).
US- 4: As a Product owner,when the phone is powered ON, I shall see the "Dictionary" icon as the second icon at the bottom bar of my screen.
Test Plan for "Dictionary" Icon Placement
Objective:
To verify that when the mobile phone is powered on, the "Dictionary" icon is displayed as the second icon at the bottom bar of the screen.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Test scenarios and test cases
- Defect tracking system
Test Approach:
- Blackbox testing
- Manual testing
- UI testing
Test Cases:
Test Case 1: "Dictionary" Icon Placement on Power On
Description: Verify that the "Dictionary" icon is displayed as the second icon at the bottom bar of the screen upon powering on the device.
Test Steps:
- Power on the device.
- Observe the bottom bar of the screen.
Expected Result: The "Dictionary" icon should be the second icon from the left at the bottom bar of the screen.
Test Execution:
- Execute the test cases manually on the testing device or emulator.
- Record observations and results for each test case.
Defect Reporting:
- If the "Dictionary" icon is not placed as the second icon on the bottom bar or if it is not visible, report the issue with detailed steps and observations.
Test Coverage:
- Test the scenario with different screen resolutions and orientations to ensure responsiveness.
Test Reporting:
- Create a test report that includes the test cases executed, their outcomes, any defects found, and overall observations.
Test Automation (Hypothetical):
- Although not mentioned in the original requirements, if test automation is considered:
- Utilize UI automation tools (e.g., Appium, Selenium) to automate the test case.
- Write test scripts to navigate to the home screen, locate and verify the placement of the "Dictionary" icon.
- Automate the verification process for different resolutions and orientations.
Conclusion:
This test plan outlines the approach to test the placement of the "Dictionary" icon as the second icon at the bottom bar of the screen. By following this plan, you can ensure that the specified requirement is met, and the icon is correctly displayed upon powering on the mobile phone. This testing should be conducted before moving to the User Acceptance Testing (UA) phase.
US- 5: As a Product owner,when I Clicked my "call the phone" icon ,all the contacts shall be visible based on chronological order.
Test Plan for "Call the Phone" Icon and Contact Display:
Objective:
To test the functionality of the "call the phone" icon and ensure that all contacts are displayed in chronological order when the icon is clicked.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Test data with contacts of varying creation timestamps
- Test users with varying contact lists
- Test cases management tool (e.g., TestRail, TestLink)
Test Approach:
- Blackbox testing
- Manual testing for initial stages
- Exploratory testing for user experience
- Automated testing for regression testing
Test Cases:
Test Case 1: "Call the Phone" Icon Functionality
Description: Verify that the "call the phone" icon functions as expected and displays the list of contacts.
Test Steps:
- Open the phone application.
- Locate and click the "call the phone" icon.
- Observe the screen for the list of contacts.
Expected Result: The application should display the list of contacts in chronological order.
Test Case 2: Contact Display Order
Description: Verify that contacts are displayed in chronological order based on creation timestamp.
Test Steps:
- Add multiple contacts with different creation timestamps.
- Click the "call the phone" icon.
- Observe the order in which contacts are displayed.
Expected Result: Contacts should be listed in chronological order, with the oldest created contact appearing first.
Test Case 3: User Experience and Interaction
Description: Verify the user experience and interaction when viewing the contact list.
Test Steps:
- Click the "call the phone" icon.
- Scroll through the contact list.
- Test interactions like tapping a contact to initiate a call.
Expected Result: The contact list should be easy to navigate, and interactions (e.g., tapping to call) should work smoothly.
Test Execution:
- Perform manual testing to validate the initial implementation.
- Conduct exploratory testing to ensure user experience is intuitive.
- Create and execute automated test scripts for regression testing as the feature stabilizes.
Test Data:
- Create a set of test data with contacts that have varying creation timestamps.
- Populate the contacts with realistic information for accurate testing.
Defect Reporting:
- If contacts are not displayed in chronological order, or if there are any issues with the "call the phone" icon functionality, report defects with detailed steps and observations.
Test Automation:
- Write automated test scripts using a suitable automation framework (e.g., Appium, Espresso).
- Automate test cases for regression testing, especially considering the continuous changes during development.
Conclusion:
This test plan outlines the testing procedure for the "call the phone" icon and contact display functionality. By following this plan, you can ensure that the feature works as intended and provides an intuitive user experience. Thorough testing before User Acceptance Testing (UA) will help identify and rectify issues early in the development process.
US- 6: As a Product owner,when I Clicked my "Dictionary icon ,a search bar shall appear at the middle of the screen to let me search the meanings of the words I desire.
Test Plan for Dictionary Icon and Search Bar Functionality
Objective:
To test the functionality of the "Dictionary" icon, ensuring that when clicked, a search bar appears at the middle of the screen, allowing users to search for word meanings.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Test cases management tool (e.g., TestRail, TestLink)
- Bug tracking system (e.g., JIRA)
Test Approach:
- Blackbox testing
- Manual testing for initial stages
- Exploratory testing to uncover unexpected issues
Test Cases:
Test Case 1: Dictionary Icon Click
Description: Verify that clicking the "Dictionary" icon triggers the appearance of the search bar.
Test Steps:
- Locate and click the "Dictionary" icon on the user interface.
- Observe the screen for changes.
Expected Result: A search bar should appear at the middle of the screen, ready for user input.
Test Case 2: Search Bar Appearance
Description: Verify the position and appearance of the search bar after clicking the "Dictionary" icon.
Test Steps:
- Click the "Dictionary" icon.
- Observe the screen to ensure that the search bar is centered and properly displayed.
Expected Result: The search bar should be visible at the middle of the screen, appropriately centered.
Test Case 3: Search Functionality
Description: Verify that the search bar allows users to search for word meanings.
Test Steps:
- Click the "Dictionary" icon.
- Enter a word into the search bar and press the "Search" button.
- Observe the screen for search results.
Expected Result: Relevant word meanings or definitions should be displayed as search results.
Test Execution:
- Perform manual testing for the initial implementation.
- Apply exploratory testing to identify any unexpected issues related to the "Dictionary" icon and search bar
Defect Reporting:
- If the search bar doesn't appear after clicking the "Dictionary" icon, or if the search results are incorrect or missing, report the issues with detailed steps and observations.
Regression Testing:
- As the product evolves, include these test cases in your regression test suite to ensure that new changes do not break the existing functionality.
Conclusion:
This test plan outlines the manual testing procedures for the "Dictionary" icon and search bar functionality. By following this plan, you can ensure that the required functionality is thoroughly tested before moving on to User Acceptance Testing (UA)
US- 7: As a Product owner,when I long pressed my "power on" button ,my phone shall be switched off saying "Good-Bye” Message.
Test Plan for Power Off Functionality ("Good-Bye" Message)
Objective:
To verify that the mobile phone's "power off" functionality works as expected when the power button is long pressed, and the device displays a "Good-Bye" message before switching off.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Test scenarios for manual testing
- Test cases for automated testing (if applicable)
Test Approach:
- Blackbox testing
- Manual testing for initial stages
- Automated testing (if implemented) for regression testing
Test Cases:
Test Case 1: Power Off with "Good-Bye" Message
Description: Verify that the device switches off and displays the "Good-Bye" message upon long pressing the power button.
Test Steps:
- Power on the device if it's not already powered on.
- Long press the "power on" button.
- Observe the screen during the power-off process.
Expected Result: The device should display a "Good-Bye" message on the screen before powering off.
Test Case 2: Power Off Behavior
Description: Verify the behavior of the device when it is powered off.
Test Steps:
- Perform a regular power-off action (short press or long press depending on the device's behavior).
- Observe the behavior of the device as it powers off.
Expected Result: The device should gracefully shut down without any abnormal behavior or errors.
Test Execution:
- Perform manual testing for the initial implementation.
- If automated testing is implemented, create and execute test scripts for regression testing using appropriate tools.
Test Data:
- None required for this specific test case.
Defect Reporting:
- If the "Good-Bye" message is not displayed, or if there are issues with the power-off process, report the issue with detailed steps and observations.
Automated Testing (if applicable):
- If automated testing is desired, consider using a test automation tool (e.g., Appium, Espresso, etc.) to create and execute test scripts.
- Write test scripts to simulate the power button long press, monitor the "Good-Bye" message, and validate the power-off process.
- Set up automated tests for regression testing during the development cycle.
Conclusion:
This test plan outlines the manual testing procedures for the "power off" functionality, including the display of the "Good-Bye" message. By following this plan, you can ensure that the power-off process meets the specified requirements before User Acceptance Testing (UA).
US-8: As a product owner ,my font in the mobile shall always be ''calibri (Body)" and shall be of size 12.
Test Plan for Font Type and Size
Objective:
To test the font type and size settings on the mobile phone and ensure that the font is always "Calibri (Body)" and of size 12 as per the requirement.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Test scenarios for manual testing
Test Approach:
- Blackbox testing
- Manual testing for font appearance and size validation
Test Cases:
Test Case 1: Default Font Settings
Description: Verify the default font settings on the mobile phone.
Test Steps:
- Power on the device.
- Navigate to a text-based application or interface.
- Observe the font type and size.
Expected Result: The default font should be "Calibri (Body)" and size 12.
Test Case 2: Font Settings Persistence
Description: Verify that the selected font settings persist across various applications and interfaces.
Test Steps:
- Access the device settings and navigate to the font settings.
- Change the font to "Calibri (Body)" and size 12.
- Open different applications (e.g., messaging, note-taking) and interfaces to observe the font.
Expected Result: The selected font settings ("Calibri (Body)" and size 12) should be consistent across all supported applications and interfaces.
Test Case 3: Font Customization
Description: Verify that users cannot change the font type and size settings to anything other than "Calibri (Body)" and size 12.
Test Steps:
- Access the device settings and navigate to the font settings.
- Attempt to change the font to a different type and size.
- Confirm the font settings and observe the appearance in various applications.
Expected Result: Users should not be able to set a font other than "Calibri (Body)" and size 12. The font should remain consistent as specified.
Test Execution:
- Perform manual testing for each test case using the testing device or emulator.
- Verify the font type and size settings across various applications and interfaces.
Defect Reporting:
- If the font appears differently than "Calibri (Body)" and size 12 or if users are able to set a different font, report the issue with detailed steps and observations.
Conclusion:
This test plan outlines the manual testing procedures to validate the font type and size settings on the mobile phone. By following this plan, you can ensure that the font settings meet the specified requirements before User Acceptance Testing (UA).
US-9:As a Customer, I need my UI to be touch responsive
Test Plan for Touch Responsiveness of UI
Objective:
To test the touch responsiveness of the user interface (UI) on the new mobile phone and ensure that user interactions are accurately detected and responded to.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
- Variety of touch gestures (tap, swipe, pinch, etc.)
- Sample UI elements for testing interactions
Test Approach:
- Blackbox testing
- Manual testing for initial stages
- Automated testing for regression testing (optional)
Test Cases:
Test Case 1: Tap Gesture
Description: Verify that the UI accurately responds to single tap gestures.
Test Steps:
- Tap on various UI elements (buttons, icons, text fields, etc.).
- Observe the response and verify if the tapped element behaves as expected.
Expected Result: The UI should respond promptly to tap gestures, and the tapped element should visually respond (highlight, change color, etc.).
Test Case 2: Swipe Gesture
Description: Verify that the UI accurately responds to swipe gestures in different directions.
Test Steps:
- Perform swipes in different directions (up, down, left, right) on scrollable areas or UI elements.
- Observe the response and verify if the content or UI elements scroll or navigate as expected.
Expected Result: The UI should respond to swipe gestures smoothly, and the content or UI elements should scroll or navigate accordingly.
Test Case 3: Pinch Gesture
Description: Verify that the UI accurately responds to pinch gestures for zooming in and out.
Test Steps:
- Perform pinch gestures on zoomable UI elements (images, maps, etc.).
- Observe the response and verify if the element zooms in and out as expected.
Expected Result: The UI should respond to pinch gestures, enabling zoom functionality for relevant elements.
Test Execution:
- Manual testing for the initial implementation, covering a wide range of touch interactions.
- Consider automating repetitive touch tests using testing frameworks and scripting for regression testing (optional).
Test Data:
- A variety of UI elements representing different touch interactions (buttons, sliders, scrollable lists, etc.).
Defect Reporting:
- Report any issues related to touch responsiveness, such as delays, missed gestures, or incorrect behavior.
- Include detailed steps to reproduce the issue and any observations.
Test Automation (Optional):
- For regression testing, consider using automated test scripts to perform repetitive touch tests.
- Utilize testing frameworks that support touch interactions and UI automation for mobile devices.
Conclusion:
This test plan outlines the manual testing procedures for evaluating the touch responsiveness of the UI on the new mobile phone. By executing these test cases, you can ensure that the touch interactions are accurately detected and responded to, enhancing the overall user experience.
US-10: As a customer, my mobile phone should have no hard buttons
Test Plan for Absence of Hard Buttons
Objective:
To verify that the new mobile phone has no physical hard buttons as per the requirement.
Testing Environment:
- Mobile phone under development
- Testing device or emulator
Test Approach:
- Blackbox testing
- Manual testing
Test Cases:
Test Case 1: Physical Examination of the Device
Description: Physically examine the mobile phone to identify the presence of any hard buttons.
Test Steps:
- Inspect the entire exterior of the mobile phone.
- Look for any buttons that protrude from the device's surface.
Expected Result: No physical hard buttons should be present on the mobile phone.
Test Case 2: Functional Button Check
Description: Verify that there are no functional hard buttons on the mobile phone.
Test Steps:
- Turn on the device (if possible) or access any available user interface.
- Carefully navigate through menus and screens to ensure that no physical hard buttons are required for navigation or interaction.
Expected Result: No physical hard buttons should be needed or used during navigation or interaction with the device.
Test Execution:
- Physically inspect the device to confirm the absence of hard buttons.
- Perform functional tests to ensure that the absence of hard buttons does not affect the user's ability to interact with the device.
Defect Reporting:
- If any physical hard buttons are found or if the absence of hard buttons affects user interaction, report the issue with detailed steps and observations.
Conclusion:
This test plan outlines the manual testing procedure to verify that the new mobile phone complies with the requirement of having no physical hard buttons. By following this plan, you can ensure that the absence of hard buttons is validated before User Acceptance Testing (UA).