Based on Learning 1, 2 and 3, develop and present a paper that demonstrates you have learned and know how to apply the learning objectives in software testing. Be sure to provide examples (charts, graphics better) of all the elements that you have learned. This should be 6-8 APA-formatted pages in length. Be aware of proper in-text citations and references, no plagiarism.Week 2 Assignment Week 2 Assignment Summary: Correcting Faults in an Online Shopping Cart Python Program In this detailed summary, we will explore a Python program that simulates an online shopping cart, identify a critical fault within the code, describe the used cases for each function, and provide solutions to correct the issues. This analysis will encompass a deep dive into the code, test cases, and the correction process to ensure the program functions correctly. In this example, we'll work with a simple function that calculates the sum of elements in a list. Here's the initial faulty code: The fault in this code is that it's subtracting each number from the result instead of adding them. We'll write tests to demonstrate the fault, then fix the code, and finally, show that all tests pass after the fix. First, let's write some test cases using Python's built-in unittest module: Fault: The initial code subtracted numbers instead of adding them. Fault Output: The faulty code produced incorrect results for all test cases. Correction: We changed result -= num to result += num to correctly calculate the sum. Testing: After the correction, all test cases passed, demonstrating that the fault has been repaired. Now, let's run the tests with the initial faulty code. You'll see that at least one of the tests will fail because of the fault in the ‘calculate_sum’ function. In my example, all three tests failed. The following screenshot in the next page shows the output of running the test. To fix the fault, we need to change result -= num to result += num in the ‘calculate_sum’ function: Now if we run the code again we will see the test is successfully passed. The successful execution of the test cases validated that the code corrections were effective, and the program now functions as intended, allowing users to interact with the online shopping cart without encountering errors. This process underscores the importance of testing and quality assurance in software development, ensuring that code operates reliably and delivers the expected functionality to end-users. Week 4 Comprehensive Assignment Research selected household appliance_ Programmable Thermostat. i. FSM: ii. abstract tests to satisfy predicate Coverage: To ensure the predicate coverage, research needs to monitor each predicate in the FSM is tested for true and false at least once (PTOLEMY, 2023). The programmable thermostat FSM contains prompts: a. temperature < temperatureoffthreshold="" b.="" temperature="">= temperatureOffThreshold c. Temperature <= temperatureonthreshold="" d.="" temperature=""> temperatureOnThreshold Now, let’s derive the following basic tests to deal with the research objectives: a. Test 1: Set the temperature below heatOffThreshold and verify that the thermostat is in heat mode. b. Test 2: Set the temperature to heatOffThreshold or higher and verify that the thermostat is in the cool position. c. Test 3: Set the temperature lower than heatOnThreshold and verify that the thermostat is in heat mode. d. Test 4: Set the temperature to heatOnThreshold or higher and verify that the thermostat is in the cool position. These detailed step by step methods will ensure that each predicated objective will cover in a programmable thermostat FSM test for true and false at least once. Also, research can use some other abstract tests that can be used to further enhancement of the procedure: a. Test 5: Set the temperature to a specific heatOffThreshold value and verify that the thermostat is in heating mode. b. Test 6: Set the temperature to a specific heatOnThreshold value and verify that the thermostat is in the cool position. c. Test 7: Take the temperature between heatOffThreshold and heatOnThreshold and verify that the thermostat is in the heating and cooling modes, depending on whether the temperature is above or below the midpoint between the two thresholds. This additional methodology will help to enhance the programmable thermostat that works with the FSM with all tentative temperature values. iii. Correlation on Active Clause Coverage: Correlated active clause coverage (CACC) is a more robust coverage test than cash coverage. In addition to requiring that each term be tested for true and false at least once, the CACC also requires that each proposition be tested for true and false while holding all other terms constant. For the programmable thermostat FSM to satisfy the CACC, research must ensure that each predicate evaluates to true and false while the other three predicates are consistent across all possible values (RESEARCHGATE, 2023). The following abstract tests can be used to verify the CACC for a programmable thermostat FSM: a. Test 1: Set the temperature below heatOffThreshold and verify that the thermostat is in heat mode. Repeat this experiment with the remaining three terms held constant across all possible values. b. Test 2: Set the temperature to heatOffThreshold or higher and verify that the thermostat is in the cool position. Repeat this experiment with the remaining three terms held constant across all possible values. c. Test 3: Set the temperature lower than heatOnThreshold and verify that the thermostat is in heat mode. Repeat this experiment with the remaining three terms held constant across all possible values. d. Test 4: Set the temperature to heatOnThreshold or higher and verify that the thermostat is in the cool position. Repeat this experiment with the remaining three terms held constant across all possible values. These tests will ensure that each predicate in a programmable thermostat FSM test for true and false when all other predicates are set to all possible values. Additional enhancement can be by using as follows steps: a. Test 5: Set the temperature to a specific heatOffThreshold value and verify that the thermostat is in heating mode. Repeat this experiment with the remaining three terms held constant across all possible values. b. Test 6: Set the temperature to a specific heatOnThreshold value and verify that the thermostat is in the cool position. Repeat this experiment with the remaining three terms held constant across all possible values. c. Test 7: Take the temperature between heatOffThreshold and heatOnThreshold and verify that the thermostat is in the heating and cooling modes, depending on whether the temperature is above or below the midpoint between the two thresholds. Repeat this experiment with the remaining three terms held constant across all possible values. iv. General Inactive Clause Coverage: General passive block coverage (GICC) is a more stringent test coverage criterion than correlated active clause coverage (CACC) (CS.BROWN, 2023). In addition to requiring that each proposition be evaluated for true and false, and that all other propositions be held constant, GICC requires that every passive proposition be a proposition that does not affect the outcome of the operation (UTAH, 2023). For the programmable thermostat FSM to satisfy the GICC, research must ensure that each passive expression evaluates to true and false when all other parameters are set. The following abstract tests can be used to satisfy the GICC for a programmable thermostat FSM: a. Test 1: Set the temperature below heatOffThreshold and verify that the thermostat is in heat mode. Repeat this test with the remaining three terms held constant over all possible values, and set the temperature < heatoffthreshold="" clause="" to="" true="" and="" false.="" b.="" test="" 2:="" set="" the="" temperature="" to="" heatoffthreshold="" or="" higher="" and="" verify="" that="" the="" thermostat="" is="" in="" the="" cool="" position.="" repeat="" this="" test="" with="" the="" remaining="" three="" terms="" held="" constant="" over="" all="" possible="" values,="" and="" set="" the="" temperature="">< heatoffthreshold="" clause="" to="" true="" and="" false.="" c.="" test="" 3:="" set="" the="" temperature="" lower="" than="" heatonthreshold="" and="" verify="" that="" the="" thermostat="" is="" in="" heat="" mode.="" repeat="" this="" test="" with="" the="" remaining="" three="" terms="" held="" constant="" over="" all="" possible="" values,="" and="" set="" the="" temperature="">= heatOffThreshold clause to true and false. d. Test 4: Set the temperature to or above heatOnThreshold and check that the thermostat is in the cool position. Repeat this test with the remaining three terms held constant over all possible values, and set the temperature >= heatOffThreshold clause to true and false. e. Test 5: Set the temperature below heatOffThreshold and verify that the thermostat is in heat mode. Repeat this test with the remaining three terms held constant across all possible values, and set the temperature <= heatonthreshold="" clause="" to="" true="" and="" false.="" f.="" test="" 6:="" set="" the="" temperature="" to="" heatoffthreshold="" or="" higher="" and="" verify="" that="" the="" thermostat="" is="" in="" the="" cool="" position.="" repeat="" this="" test="" with="" the="" remaining="" three="" terms="" held="" constant="" across="" all="" possible="" values,="" and="" set="" the="" temperature=""><= heatonthreshold="" clause="" to="" true="" and="" false.="" g.="" test="" 7:="" set="" the="" temperature="" lower="" than="" heatonthreshold="" and="" check="" that="" the="" thermostat="" is="" in="" the="" heat="" position.="" repeat="" this="" test="" with="" the="" remaining="" three="" terms="" held="" constant="" over="" all="" possible="" values,="" and="" set="" the="" temperature=""> heatOnThreshold clause to true and false. h. Test 8: Set the temperature to heatOnThreshold or higher and verify that the thermostat is in the cool position. Repeat this test with the remaining three terms held constant over all possible values, and set the temperature > heatOnThreshold clause to true and false. Reference: Claudius Ptolemaeus, Editor, Systems Design, Modeling, and Simulation using Ptolemy II, Ptolemy.org, 2014. Lee, Edward. (2011). Finite State Machines and Modal Models in Ptolemy II. https://users.cs.utah.edu/~rajeev/cs3810/fsm-notes.pdf Lee&Seshia, IntroductiontoEmbeddedSystems, Solutions, 2023 https://users.cs.utah.edu/~rajeev/cs3810/fsm-notes.pdf Learning3 SOFTWARE TEST PROCESSES with E-commerce Website Requirements Analysis: 1. Functional Requirements: ● Users should be able to browse products. ● Users can add products to a shopping cart. ● Users can create an account and log in. ● Users can make purchases and check out. ● Admins can manage products and user accounts. ● Users can leave product reviews and ratings. 2. Non-Functional Requirements: ● The website should load within 3 seconds. ● User data should be securely stored. ● The website should be responsive and work on mobile devices. ● Payment transactions should be encrypted. ● User passwords should be hashed and salted for security. Test Planning: 1. Test Objectives: ● Ensure all key functionalities work as expected. ● Validate the security and performance of the website. ● Confirm that business rules are correctly applied. 2. Test Levels: a. Unit Testing: ● Test individual functions and methods within the code. ● Verify that functions like adding products to the cart or calculating discounts work correctly. b. Integration Testing: ● Test the interactions between different components (e.g., the shopping cart module, user authentication, and payment processing). ● Ensure that data flows seamlessly between components. c. System Testing: ● Validate the entire system's functionality. ● Test user journeys from browsing products to completing a purchase. d. Performance Testing: ● Test website load times with simulated user traffic. ● Check how the system handles concurrent user interactions. e. Security Testing: ● Perform penetration testing to identify vulnerabilities. ● Verify data encryption and user authentication mechanisms. Test Strategy: E-commerce Website 1. Test Objectives: ● Ensure the e-commerce website meets the defined requirements and specifications. ● Verify the website's functionality, performance, security, and usability. ● Detect and report defects early in the development cycle. ● Achieve a high level of test coverage to minimize post-release issues. 2. Test Levels: a. Unit Testing: ● Focus on testing individual components, functions, and methods. ● Performed by developers during the development phase. ● Use test frameworks like JUnit and Mockito for Java components. b. Integration Testing: ● Verify the interactions between various modules and components. ● Ensure data flows correctly between the shopping cart, user authentication, and payment processing. ● Use integration testing frameworks such as REST Assured for API testing. c. System Testing: ● Validate the entire system's functionality, including user interfaces, user journeys, and database interactions. ● Test different user roles (e.g., customers, admins) and scenarios (e.g., adding items to the cart, completing orders). ● Employ tools like Selenium WebDriver for UI testing. d. Performance Testing: ● Evaluate the website's performance under different loads. ● Measure response times, throughput, and resource utilization. ● Use Apache JMeter for load and stress testing. e. Security Testing ● Identify vulnerabilities, weaknesses, and security flaws in the application. ● Conduct penetration testing, code reviews, and vulnerability scanning. ● Utilize tools like OWASP ZAP and Burp Suite. 3. Test Environment: ● Development Environment: Used for unit testing and initial integration testing. ● Staging Environment: A replica of the production environment for comprehensive system testing. ● Performance Testing Environment: Configured with load-testing tools and infrastructure. ● Security Testing Environment: Isolated environment for security assessments. 4. Test Data: ● Generate test data to cover various scenarios, including different product types, user profiles, and order histories. ● Anonymized production data may be used for performance and security testing. 5. Test Cases: ● Develop test cases based on requirements, user stories, and use cases. ● Include positive and negative scenarios, boundary tests, and exceptional cases. ● Maintain traceability between test cases and requirements. 6. Test Execution: ● Execute test cases according to test plans and schedules. ● Automate repetitive tests to improve efficiency and accuracy. ● Continuously monitor test execution and log test results. 7. Defect Management: ● Use a defect tracking tool (e.g., JIRA) to report, track, and prioritize defects. ● Assign defects to development teams for resolution. ● Perform regression testing after defect fixes. 8. Test Reporting: ● Regularly generate test reports to communicate progress and findings to stakeholders. ● Include pass/fail status, defect summaries, and metrics (e.g., test coverage, performance benchmarks). 9. Test Completion Criteria: