To test the total cost calculation, I would use the following categories of test data:

• Positive Test Data: This data includes valid combinations of items in the cart with correct prices and quantities.
  

  
  

  Purpose: Verifies that the system correctly calculates the total cost when everything is valid. It confirms the core functionality is working as expected.

• Zero Quantity Data: This data involves items with a quantity of zero.
  

  
  

  Purpose: Checks if the system handles zero quantities correctly, ensuring that items are not added to the total cost unintentionally or that the total cost is appropriately adjusted.

• Large Quantity Data: This data involves items with very large quantities.
  

  
  

  Purpose: Tests the system's ability to handle large numbers and prevent potential overflow errors or performance issues. It also checks for limitations on the maximum quantity of an item that can be added to the cart.

• Discount Data: This data includes items with discounts applied (e.g., percentage discounts, fixed amount discounts).
  

  
  

  Purpose: Verifies that discounts are applied correctly and that the total cost is calculated accurately after applying discounts. It tests the discount logic within the system.

• Mixed Data: This data combines different scenarios, such as items with varying quantities, discounts, and potentially invalid inputs (e.g., negative quantities).
  

  
  

  Purpose: Tests the system's robustness and ability to handle complex combinations of inputs. It helps identify potential interactions between different parts of the system.

Analysis: The current program uses a list of tuples, which is a simple data structure. However, it lacks structure and doesn't enforce data integrity. The absence of error handling makes the program vulnerable to crashes due to invalid user input. The limitation on multiple books by the same author is a significant functional deficiency. The user experience is basic, lacking clear prompts and feedback.

Proposed Amendments:

• Data Structure: Replace the list of tuples with a class called Book with attributes for title, author, and potentially publication_year. This provides better data encapsulation and organization. A Library class could then manage a list of Book objects.
• Error Handling: Implement try-except blocks to handle potential errors, such as invalid user input (e.g., non-numeric input when expecting a number). Provide informative error messages to the user.
• Multiple Books by Author: Allow for multiple books by the same author by modifying the Book class to include an author_name attribute (which could be a list if an author has multiple names).
• User Experience: Improve the user interface with clear prompts, validation of user input, and informative output. Consider using a loop to allow the user to perform multiple actions without restarting the program.
• Data Persistence: Consider adding functionality to save and load the library data to a file (e.g., using JSON or a database) to prevent data loss.

There are several types of system maintenance, each addressing different aspects of system health. Here's a comparison:

Each type of maintenance serves a distinct purpose, and a well-maintained system requires a combination of all four.