Project 1 - V&V SW Analysis - I

  // US-1: Power on the phone with company logo on the screen
    if (powerButtonLongPressed == 1) {
        powerOn = 1;
        printf("Phone switched on with company logo.");
    }

    // US-2: Icons present on the home screen grid
    if (powerOn == 1) {
        printf("Home screen icons present in the grid.");
    }

    // US-3: "Call the phone" icon at the bottom bar
    if (powerOn == 1) {
        printf("Call the phone icon displayed as the first icon at the bottom bar.");
    }

    // US-4: "Dictionary" icon at the bottom bar
    if (powerOn == 1) {
        printf("Dictionary icon displayed as the second icon at the bottom bar.");
    }

    // US-5: View contacts when "Call the phone" icon is clicked
    if (callPhoneClicked == 1) {
        printf("Displaying contacts based on chronological order.");
    }

    // US-6: Display search bar when "Dictionary" icon is clicked
    if (dictionaryClicked == 1) {
        printf("Search bar for dictionary displayed at the middle of the screen");
    }

    // US-7: Power off the phone with "Good-Bye" message
   
    if (powerButtonLongPressedOff == 1) {
        powerOff = 1;
        printf("Phone switched off with Good-Bye message.");
    }

    // US-8: Font type and size consistency
    char fontType[20] = "calibri (Body)";
    int fontSize = 12;
    printf("Font type: %s, Font size: %d.\n", fontType, fontSize);

    // US-9: UI touch responsiveness
     if (touchResponsive == 1) {
        printf("UI is touch responsive.");
    }

    // US-10: No hard buttons
    
    if (hardButtons == 0) {
        printf("No hard buttons on the mobile phone.");
    }

   

TEST PLAN :-

A test plan is a document that outlines the approach, objectives, scope, and schedule for testing a software system. It serves as a comprehensive guide for the testing process and provides a roadmap for the testing team to follow. The test plan is typically created during the early stages of software development and is continuously updated throughout the testing phase. Here are the key components typically included in a test plan for software verification and validation:

1. Test Objectives:

Clearly state the overall goals and objectives of the testing effort, such as identifying defects, ensuring functional correctness, assessing performance, or validating user requirements.

2. Test Scope:

Define the boundaries and extent of the testing effort, including which features, modules, or components will be tested and any specific areas or functionalities that will be excluded from testing.

3. Test Approach:

Describe the overall strategy and approach for testing, including the types of testing to be performed (e.g., unit testing, integration testing, system testing, acceptance testing), the testing techniques and methodologies to be employed, and any specific tools or frameworks that will be used.

4. Test Deliverables:

Specify the key documents and artifacts that will be produced during testing, such as test cases, test scripts, test data, test logs, and defect reports.

5. Test Environment:

Describe the hardware, software, and network configurations required for testing, including details about the test environment setup, test data setup, and any dependencies or prerequisites.

6. Test Schedule:

Provide a timeline and milestones for the testing activities, including estimated start and end dates for each testing phase, as well as any dependencies on other project activities.

7. Test Resources:

Identify the roles and responsibilities of the testing team members, including test managers, testers, test designers, and any external resources or tools that will be utilized. Also, consider the availability of hardware, software licenses, and other resources needed for testing.

8. Test Execution:

Outline the specific test procedures, including steps to execute the tests, criteria for determining test pass/fail, expected results, and any test data or configurations that need to be prepared.

9. Test Risks and Mitigation:

Identify the potential risks and challenges associated with the testing process, such as resource constraints, schedule delays, inadequate test coverage, or insufficient test data. Provide mitigation strategies and contingency plans to address these risks.

10. Test Metrics and Reporting:

Specify the metrics and measurements that will be collected during testing, such as defect density, test coverage, and test execution status. Describe the reporting mechanisms and frequency of status updates and test reports.

11. Defect Management:

Define the process for reporting, tracking, and resolving defects or issues discovered during testing. Include guidelines for defect prioritization, severity classification, and the roles and responsibilities of team members involved in defect management.

12. Acceptance Criteria:

Clearly state the criteria that must be met for the software system to be considered acceptable or ready for release. This may include specific performance benchmarks, functional requirements, or user satisfaction metrics.

By creating and following a well-defined test plan, the verification and validation process becomes more structured, efficient, and effective. It helps ensure that the software system meets the required quality standards and delivers the desired functionality to end-users.

*************************************************************************************

BLACK BOX TESTING:-

Black box testing is a software testing technique that focuses on examining the functionality of a software system without considering its internal structure or implementation details. In black box testing, the tester is only concerned with the inputs to the system and the corresponding outputs or behavior, treating the system as a "black box" where the internal workings are unknown.

The main objective of black box testing is to evaluate the system's compliance with specified requirements and to identify any discrepancies or defects that may exist. It is typically performed from a user's perspective, without any knowledge of the internal code, algorithms, or design of the software system.

Key Characteristics of Black Box Testing:

1. No knowledge of internal implementation: The tester has no access to the source code, design documents, or internal details of the system being tested. The focus is solely on the system's inputs, outputs, and behavior.

2. Testing based on specifications: The testing is based on the documented requirements, user stories, functional specifications, or any other form of specification that describes the expected behavior of the system.

3. Test cases derived from inputs and expected outputs: Test cases are designed to cover a range of possible inputs and verify that the outputs or behavior of the system meet the specified requirements.

4. Independent of programming languages or technologies: Black box testing can be applied to any software system regardless of the programming language, technology stack, or underlying architecture.

5. Emphasis on functionality, usability, and requirements validation: Black box testing primarily focuses on ensuring that the system functions correctly, adheres to user requirements, and is usable from an end-user perspective.

Common Black Box Testing Techniques:

1. Equivalence Partitioning:

Dividing input data into classes or partitions to create test cases that represent each partition, assuming that the behavior within a partition is similar.

2. Boundary Value Analysis:

Testing the system's behavior at the boundaries or edges of input ranges, as defects often occur near boundary conditions.

3. Decision Table Testing:

Creating a matrix that maps combinations of inputs to expected outputs or system behavior, enabling systematic testing of various scenarios.

4. State Transition Testing:

Testing the system's behavior as it transitions between different states, often used for systems with explicit states or state diagrams.

5. Error Guessing:

Based on the tester's intuition and experience, identifying potential errors or problem areas in the system and designing test cases to target those areas.

Advantages of Black Box Testing:

- Independent of internal implementation, allowing testing to be performed by individuals who are not involved in development.
- Focuses on the system's external behavior, which aligns with end-user expectations and requirements.
- Can detect defects related to incorrect functionality, usability, performance, and compatibility.
- Encourages a user-centric approach, leading to improved user satisfaction and experience.

Limitations of Black Box Testing:

- Limited in uncovering defects related to internal code issues, algorithmic problems, or performance bottlenecks.
- Requires clear and comprehensive specifications or requirements to design effective test cases.
- Test coverage may be limited if all possible input combinations and scenarios are not explored.

Black box testing complements other testing techniques, such as white box testing (which examines the internal structure and code of the system) and gray box testing (which combines elements of both black box and white box testing). By applying a combination of testing techniques, a more comprehensive assessment of the software system's quality can be achieved.