Software Testing & Validation: Types, Techniques & Quality Assurance

Core Concepts: Testing vs. Validation

1. Definitions & Key Differences

Software testing is the process of executing a program to find errors, while validation ensures the software meets user requirements. Verification checks if the software was built correctly (e.g., code reviews, syntax checks).

stateDiagram-v2
    [*] --> Verification: "Built correctly?"
    Verification --> Validation: "Meets requirements?"
    Validation --> [*]
    Validation --> Defects: "No" --> Fixes --> [*]

Why validation is harder:

• Requires user involvement (e.g., beta testing).
• Ambiguous requirements (e.g., "fast checkout" in eSewa).
• Environmental factors (e.g., Ncell app crashes on older Android versions).

Example: A bank’s loan calculator (validation) must correctly compute EMI, but verification ensures the code handles edge cases (e.g., 0% interest).

2. Types of Testing

A. Levels of Testing

B. Black-Box vs. White-Box Testing

Worked Example (Black-Box): For a Khalti payment app, design test cases for:

1. Valid Input: ₹500 → Success.
2. Invalid Input: ₹0 → Error: "Amount too low."
3. Edge Case: ₹999,999,999 → Overflow check.

3. Test Case Design Techniques

A. Equivalence Partitioning

Divide inputs into valid/invalid groups:

• eSewa Transaction: Valid = ₹100–₹50,000; Invalid = ₹0 or ₹50,001.

B. Boundary Value Analysis

Test edges of partitions:

• Daraz Order: Test 1 item, 100 items, and 101 items (max limit).

C. Path Testing (Decision Coverage)

Ensure all branches are tested:

graph TD
    A["Start"] --> B{"Is User Logged In?"}
    B -->|"Yes"| C["Show Dashboard"]
    B -->|"No"| D["Redirect to Login"]
    C --> E["End"]
    D --> E

Example: Test both paths in NEPSE trading app (logged-in vs. guest).

4. Specialized Testing Techniques

A. Static vs. Dynamic Testing

B. Performance Testing

• Load Testing: Simulate 10,000 concurrent users on eSewa.
• Stress Testing: Crash Daraz’s server by spamming orders.
• Volume Testing: Test NTC’s database with 1M+ records.

C. Security Testing

• Penetration Testing: Hack Khalti’s API to find vulnerabilities.
• Authentication Testing: Verify Ncell’s OTP system blocks brute-force attacks.

5. Test Metrics & Coverage

Worked Example (Coverage): For a bank loan EMI calculator:

• Statement Coverage: Did principal * rate execute?
• Branch Coverage: Did if (rate > 10) and else run?

6. Test Automation Tools

7. Validation Techniques

A. Alpha & Beta Testing

B. Prototyping for Validation

• Throwaway Prototype: Quick mockup of eSewa’s QR code scanner to validate UI.
• Evolutionary Prototype: Iteratively improve Pathao’s ride-matching algorithm.

8. Defect Classification

In the Real World

1. eSewa’s Transaction Validation:

   • Uses black-box testing for payment flows (e.g., "Pay Bill" button).
   • Load testing simulates 50,000 transactions/hour during Dashain.

2. Daraz’s Order Queue:

   • Path testing ensures orders are processed in FIFO order (no starvation).
   • Stress testing checks if the system crashes during sales (e.g., 60% off).

3. Kathmandu Traffic Simulation:

   • Model-based testing validates traffic light timings using system dynamics.
   • Beta testing with real drivers via a mobile app prototype.

4. Ncell’s Billing System:

   • White-box testing verifies calculateBill() handles all tariff plans.
   • Security testing checks for SIM-swap vulnerabilities.

Exam Tip

1. COCOMO Model (Past Exam):

   • For Organic mode: Use E = 2.4 × (KLOC)^1.05.
     • Example: 320 KLOC → E = 2.4 × 320^1.05 ≈ 793.6 person-months.
   • For Embedded mode: Use E = 3.6 × (KLOC)^1.20.
     • Example: E = 3.6 × 320^1.20 ≈ 1,587.2 person-months.

2. Verification vs. Validation:

   • Verification: "Did we build it right?" (e.g., code reviews).
   • Validation: "Did we build the right thing?" (e.g., user acceptance).

3. Test Case Design:

   • Always include normal, boundary, and invalid inputs.
   • For path testing, draw a decision table (like the EMI example).

4. Real-World Links:

   • Tie load testing to eSewa/Daraz.
   • Tie security testing to Khalti/Ncell.
   • Tie prototyping to Pathao’s app updates.

5. Avoid Common Mistakes:

   • Don’t confuse unit testing (code) with acceptance testing (users).
   • Don’t skip edge cases (e.g., empty cart in Daraz).
   • Always measure coverage (e.g., "90% branch coverage achieved").

Visual Summary:

mindmap
  root((Software Testing))
    Types
      Unit
      Integration
      System
      Acceptance
    Techniques
      Black-Box
      White-Box
      Path Testing
    Metrics
      Coverage
      Defect Density
    Tools
      Selenium
      JUnit
      JMeter
    Real-World
      eSewa: Validation
      Daraz: Load Testing
      Ncell: Security