CPSOFT30-A03
SOFTWARE CODING
AND TESTING
PRESENTED BY
Arela, Dean Aaron
Batarao, Jhove Martin
Cabuang, Thristian
Hemady, Miguel Raul
PRESENTED TO
Engr. Marwin B. Alejo
IMPROVED CODE
Renamed the function from calc to
calculate_final_price for better clarity and
readability.
Replaced short variable names (p, d, t) with more
meaningful ones: price, discount, and tax_rate.
Rewrote the docstring using the correct triple-
double quotes format, including clear explanations
of the function’s purpose and the expected input
parameters.
Added input validation to ensure that negative
values are not accepted and that discount and
tax_rate values stay within the 0–1 range.
Implemented proper error handling to catch invalid
inputs and raise appropriate exceptions.
Added inline comments to document key
calculations and improve code maintainability.
AI GENERATED TEST CASES
HAPPY PATH TEST CASE
AI GENERATED TEST CASES
EDGE TEST CASE
AI GENERATED TEST CASES
INVALID INPUT CASES
AI GENERATED TEST CASES
HAPPY PATH TEST CASE EDGE TEST CASE INVALID INPUT CASES
The most critical test cases for the calculate_final_price function are those that verify its core
calculation accuracy, such as applying a 15% discount and 12% tax to a base price of 1000. It is
also essential to test baseline cases where no discount or tax is applied to ensure the
function correctly returns the original price. Boundary cases like applying a full 100%
discount, which should result in zero, and applying a maximum 100% tax, which should
double the price, are equally important to confirm correct handling of extreme values. Input
validation tests are critical as well, particularly cases with negative prices or discounts greater
than 1, since they ensure the function rejects invalid inputs rather than producing incorrect
results. Finally, precision and rounding tests are crucial, as the function must consistently
round results to two decimal places to maintain accuracy in currency calculations.
EFFECTIVENESS OF AI
Logical Bug in the Function
The bug lies in the assumption about the order of operations between discount and tax. The function
currently applies the tax after the discount ((price × (1 – discount)) × (1 + tax_rate)), but in many real-world
contexts (such as VAT or sales tax), tax is applied on the original price before the discount, or calculated
separately. This mismatch means the function may return values that don’t align with expected business
rules, depending on jurisdiction or requirements.
Effectiveness of the AI in Finding It
The AI was fairly effective in identifying the issue:
It correctly spotted that the calculation order could be wrong.
It explained with an example how different interpretations of “tax vs. discount order” can lead to different
results.
However, it didn’t immediately declare it a “bug” in the strict sense, but rather flagged it as a potential
business logic error. This distinction is important: mathematically, the code is fine; the issue arises only if
the intended tax application order differs from what was coded.
EFFECTIVENESS OF AI
Pros of Using AI for Debugging
Speed: AI can quickly review logic and suggest potential flaws without running the code.
Broad Perspective: It considers not just syntax, but also domain/business logic issues that humans might
overlook.
Explanations: Provides reasoning and examples to illustrate the problem, which is useful for learning.
Coverage: AI often suggests additional test scenarios (like edge cases, invalid inputs) that strengthen
validation.
Cons of Using AI for Debugging
Overgeneralization: AI may flag something as a bug when it’s actually a valid design choice (false
positives).
Context Sensitivity: Without clear business rules, AI can’t know whether tax should apply before or after
discount; it can only highlight the ambiguity.
Lack of Execution: Unlike a debugger, AI doesn’t run the code, so it may miss runtime-specific issues.
Reliance Risk: Developers might over-reliance on AI and miss the opportunity to reason through the logic
themselves.
AI-GENERATED TEST PLAN OUTLINE
Test Plan Outline: Payment Processing Module
1. Introduction
Purpose: To validate the functionality, security, and reliability of the payment processing module in the e-
commerce application.
Scope: Covers card payments, digital wallets, and payment gateway integrations.
Out of Scope: Backend f inancial reconciliation, f raud detection algorithms.
2. Objectives
Ensure accurate processing of payments.
Verify integration with third-party payment gateways.
Validate error handling and transaction rollback.
Conf irm PCI compliance and data security.
3. Test Items
Payment methods (Credit/Debit cards, PayPal, Apple Pay, Google Pay)
Order checkout workflow
Payment gateway APIs (e.g., Stripe, PayPal)
Transaction success/failure handling
Refund and cancellation flow
AI-GENERATED TEST PLAN OUTLINE
4. Test Types
Functional Testing
Integration Testing
Regression Testing
Security Testing
Performance Testing
User Acceptance Testing (UAT)
5. Test Scenarios (Examples)
Successful payment with valid card details
Failed payment with invalid/expired card
Payment timeout or gateway unavailability
Duplicate transaction prevention
Handling of network interruption during payment
Refund processing and validation
Currency and tax calculations
Payment confirmation email or receipt
AI-GENERATED TEST PLAN OUTLINE
6. Test Data Requirements
Valid and invalid card details (using test cards from payment gateway)
User accounts with cart items
Different currencies and tax regions
7. Test Environment
Staging server with sandboxed payment gateway
Secure network environment
Mobile and web platforms
8. Roles & Responsibilities
QA Engineer: Test execution, reporting
Developer: Bug f ixing and test support
Product Manager: Requirement validation
Security Analyst: Security compliance review
AI-GENERATED TEST PLAN OUTLINE
9. Entry & Exit Criteria
Entry: Code complete, environment ready, test data available
Exit: All critical and major test cases passed, no blocker bugs
10. Risks & Mitigation
Risk: Payment gateway downtime
Mitigation: Use sandbox/test gateway environment
Risk: Incomplete test data
Mitigation: Preload test cases with gateway-provided test cards
CPSOFT30-A03
SOFTWARE CODING
AND TESTING
PRESENTED BY
Arela, Dean Aaron
Batarao, Jhove Martin
Cabuang, Thristian
Hemady, Miguel Raul
PRESENTED TO
Engr. Marwin B. Alejo