Software Testing & Maintenance: Techniques, Models & Real-World Impact

TAKEAWAYS:

• Testing techniques are classified by scope (unit, integration, system) and method (black-box vs. white-box), each targeting different error types (e.g., black-box tests functional gaps, white-box tests code paths).
• Maintenance phases (corrective, adaptive, perfective, preventive) account for 60–80% of software lifecycle costs—Nepal’s NTC’s mobile app updates after policy changes exemplify adaptive maintenance.
• COCOMO model estimates effort/cost via three modes (organic, semi-detached, embedded) and uses KLOC (thousands of lines of code) as a key metric—e.g., a 50-KLOC eSewa module might cost $250K in organic mode.
• Test case design follows equivalence partitioning and boundary value analysis—e.g., validating Daraz’s checkout process for 1–10 items (boundary) and bulk discounts (partition).
• Maintenance challenges include technical debt (e.g., legacy Kathmandu traffic management systems) and reverse engineering (e.g., analyzing Pathao’s ride-matching algorithms).
• Exam focus: Compare testing techniques, explain COCOMO with a worked example, and link maintenance to real-world systems (banks, e-commerce).

1. Software Testing: Fundamentals and Techniques

Software testing ensures a program meets requirements and quality standards by identifying defects. It is not about proving correctness but about finding errors.

1.1 Testing Levels (Scope-Based Classification)

Testing is categorized by the granularity of the software component being tested:

Key Definitions:

• Unit Testing: Tests smallest testable units (functions, methods). Tools: JUnit (Java), pytest (Python).
• Integration Testing: Tests interactions between units. Approaches:
  • Big Bang: All units integrated at once (risky).
  • Incremental: Step-by-step (e.g., top-down or bottom-up).
• System Testing: Validates complete system against requirements. Types:
  • Functional: Tests features (e.g., WhatsApp’s end-to-end encryption).
  • Non-functional: Tests performance, security, usability (e.g., YouTube’s load time).
• Acceptance Testing: Validates system for end-users (e.g., NTC’s app usability by citizens).

Worked Example: Daraz’s Order Fulfillment

• Unit Test: Verify calculate_discount() for 5% off orders > $50.
• Integration Test: Ensure order_placed() triggers update_inventory().
• System Test: Simulate 10,000 concurrent users to check server response time.

1.2 Testing Techniques (Method-Based Classification)

Testing methods differ by visibility into the code and error focus:

Worked Example: eSewa Transaction Validation

• Black-Box Test Case:
  • Input: User enters Rs. 500, valid PIN, recipient’s phone number.
  • Expected Output: Transaction succeeds; sender/receiver notified.
  • Boundary Test: Input Rs. 0.01 (minimum) and Rs. 1,000,000 (maximum limit).
• White-Box Test Case:
  • Verify validate_pin() function checks PIN length (4 digits) and regex ^\d{4}$.

1.3 Test Case Design

A test case includes:

1. Test ID: Unique identifier (e.g., TC_001).
2. Description: Purpose of the test.
3. Input: Data provided.
4. Expected Output: Correct result.
5. Actual Output: Result observed (filled during execution).
6. Status: Pass/Fail.

Example: Ncell Billing System

Equivalence Partitioning for NEPSE Trading App:

• Valid Partitions:
  • Share price within trading range (e.g., Rs. 100–10,000).
  • Valid user credentials.
• Invalid Partitions:
  • Price = Rs. 0 or Rs. 100,001.
  • Expired session token.

2. Software Maintenance

Maintenance is the process of modifying software post-deployment to correct faults, improve performance, or adapt to changes. It consumes 50–80% of software lifecycle costs.

2.1 Maintenance Types

pie
    title Software Maintenance Types
    "Corrective (25%)" : 25
    "Adaptive (20%)" : 20
    "Perfective (40%)" : 40
    "Preventive (15%)" : 15

Worked Example: NTC’s Mobile App Update

• Scenario: Government announces new electricity tariffs.
• Maintenance Type: Adaptive.
• Steps:
  1. Analyze new tariff rules.
  2. Update calculate_bill() function.
  3. Test with sample inputs (e.g., 100 units, 200 units).
  4. Deploy update and monitor user feedback.

2.2 Maintenance Challenges

1. Technical Debt: Shortcuts taken during development (e.g., Kathmandu traffic management system’s outdated code).
2. Reverse Engineering: Understanding legacy systems (e.g., analyzing Pathao’s ride-matching algorithm).
3. Configuration Management: Tracking changes across versions (e.g., Daraz’s seasonal sale updates).
4. User Resistance: End-users may reject changes (e.g., Ncell’s forced app update).

Real-World Impact:

• eSewa: Corrective maintenance after the 2022 cyberattack required 3 months to restore trust.
• NTC: Adaptive maintenance for new tariffs caused 2 weeks of downtime during implementation.

3. COCOMO Model for Cost Estimation

Constructive Cost Model (COCOMO) estimates effort, cost, and schedule based on lines of code (LOC) and project attributes.

3.1 COCOMO Modes

COCOMO has three modes, differing in complexity and team size:

Formula:

• Effort (E) in person-months:
  • Organic: $E=2.4\times (KLOC{)}^{1.05}$
  • Semi-Detached: $E=3.0\times (KLOC{)}^{1.12}$
  • Embedded: $E=3.6\times (KLOC{)}^{1.20}$
• Development Time (T) in months: $T=2.5\times (E^{0.38})$
• Cost (C): $C=E\times \text{Average Salary}$

Worked Example: eSewa Payment Module

• KLOC: 20 (20,000 lines of code).
• Mode: Organic (small team, simple logic).
• Effort: $E=2.4\times (20{)}^{1.05}=2.4\times 21.06=50.54$ person-months.
• Time: $T=2.5\times (50.54{)}^{0.38}\approx 8.5$ months.
• Cost (assuming $3,000/month per developer): $C=50.54\times 3,000=\$151,620$.

3.2 COCOMO Cost Drivers

COCOMO adjusts effort using 15 cost drivers (e.g., product attributes, hardware constraints, personnel experience). Example multipliers:

Adjusted Effort: $E_{\text{adjusted}}=E\times \text{Multiplier}$

Example: If eSewa’s module has high reliability needs (multiplier = 1.15) and low analyst capability (multiplier = 1.19): $E_{\text{adjusted}}=50.54\times 1.15\times 1.19\approx 69.8$ person-months.

4. Relationship Between Testing and Maintenance

Testing and maintenance are interdependent:

• Testing identifies defects that require corrective maintenance.
• Maintenance introduces changes that need re-testing.
• Preventive maintenance (e.g., refactoring) improves testability.

Example Workflow for Daraz’s Seasonal Sale:

1. Test: Validate discount logic for 50% off.
2. Maintain: Fix bug where discounts apply to shipping.
3. Re-test: Verify fixed logic with boundary values (e.g., Rs. 1, Rs. 10,000).

5. Tools for Testing and Maintenance

In the Real World

1. eSewa’s Transaction Validation

   • Idea Used: Black-box testing (equivalence partitioning for amount ranges) and white-box testing (validating PIN encryption logic).
   • How: Testers design cases for valid/invalid amounts (e.g., Rs. 0.01, Rs. 1,000,000) and edge cases like concurrent transactions during festivals.

2. Daraz’s Order Fulfillment System

   • Idea Used: Integration testing (cart + payment + inventory modules) and COCOMO for estimating effort to add new features like "Buy 1 Get 1 Free."
   • How: COCOMO predicts that adding this feature (estimated 15 KLOC) in semi-detached mode would require ~40 person-months and 6 months of development.

3. NTC’s Smart Metering App

   • Idea Used: Adaptive maintenance (updating tariff calculations) and preventive maintenance (refactoring legacy code for scalability).
   • How: After a policy change, NTC’s team uses boundary value analysis to test new tariff brackets (e.g., 0–50 units, 51–100 units) and reverse engineering to understand the old system’s logic.

Exam Tip

1. COCOMO Questions:

   • Always state the mode (organic/semi-detached/embedded) and show calculations step-by-step.
   • Memorize the effort formula and time formula.
   • For adjusted effort, list 2–3 cost drivers and their multipliers.

2. Testing Technique Comparisons:

   • Black-box vs. White-box:
     • Black-box: No code knowledge, tests functionality (e.g., "Does the login work?").
     • White-box: Code knowledge, tests paths (e.g., "Does the for loop execute 10 times?").
   • Unit vs. Integration Testing:
     • Unit: Tests individual components (e.g., a single function).
     • Integration: Tests component interactions (e.g., database + UI).

3. Maintenance Types:

   • Corrective = fixing bugs (e.g., eSewa crash).
   • Adaptive = changing environment (e.g., NTC tariff update).
   • Perfective = adding features (e.g., Daraz dark mode).
   • Preventive = avoiding future issues (e.g., refactoring Pathao’s code).

4. Worked Examples:

   • Always tie to a real system (e.g., "For eSewa’s payment module...").
   • Use boundary values (e.g., minimum/maximum amounts) and equivalence classes (e.g., valid/invalid inputs).

5. Diagrams:

   • Mermaid diagrams for testing levels, maintenance types, and COCOMO modes.
   • Tables for comparing techniques (black-box vs. white-box) or cost drivers.