SQA & Testing: Levels, Principles, QA Plans & SCM

TAKEAWAYS:

• Quality factors (correctness, reliability, efficiency, usability, maintainability, portability) define software excellence—measure them to avoid failures like Khalti’s 2021 payment glitches.
• Verification vs. Validation: Verification checks if the product is built right (coding standards), while validation checks if the right product is built (user needs).
• Testing levels (unit → integration → system → acceptance) mirror how Pathao’s ride-matching system tests driver-app communication before full deployment.
• SCM (baselines, version control, change control) prevents chaos in collaborative projects—like Nepal Rastra Bank’s core banking system updates.
• SQA plans document who tests what, when, and how—critical for audits (e.g., NTC’s network software compliance).
• Test strategies (equivalence partitioning, boundary value, cause-effect) catch edge cases—e.g., Daraz’s "out of stock" bug at peak sales.

1. Software Quality Assurance (SQA): The Foundation

SQA is proactive—it’s about preventing defects, not just finding them. Unlike testing (reactive), SQA includes:

• Process standards (ISO/IEC 12207, CMMI).
• Reviews (walkthroughs, inspections).
• Metrics (defect density, test coverage).
• Automation (CI/CD pipelines).

Key Quality Factors

Software quality is measured by non-functional attributes. The ISO 9126 model defines these factors:

2. Verification vs. Validation: The Core Difference

Why both matter:

• Verification catches coding errors (e.g., Nepal Rastra Bank’s interest calculation bug).
• Validation catches misaligned requirements (e.g., eSewa’s failed fingerprint authentication).

3. Testing Levels: From Code to User Hands

Testing happens in layers, like peeling an onion. Each level has specific goals:

graph TD
    A["Unit Testing"] --> B["Integration Testing"]
    B --> C["System Testing"]
    C --> D["Acceptance Testing"]
    A -->|"Tests individual modules"| E["Example: eSewa's payment module"]
    B -->|"Tests module interactions"| F["Example: Daraz's cart + checkout"]
    C -->|"Tests full system"| G["Example: Ncell's 4G network"]
    D -->|"Tests with real users"| H["Example: Pathao's beta riders"]

A. Unit Testing

• What? Tests smallest code units (functions, methods).
• How? White-box testing (code visibility).
• Tools: JUnit (Java), pytest (Python), NUnit (.NET).
• Example:

  def calculate_interest(principal, rate, time):
      return principal * rate * time / 100
  

  Test Case: calculate_interest(10000, 5, 1) → 500 (correct). Bug: If time is 0, should it return 0? (Edge case!)

B. Integration Testing

• What? Tests interactions between modules.
• Types:
  • Big Bang: All modules at once (risky).
  • Incremental: Top-down or bottom-up.
• Example:
  • Daraz’s order system must correctly pass data from Cart → Payment → Shipping.
  • Ncell’s billing system must sync with customer database.

C. System Testing

• What? Tests the complete system against requirements.
• Types:
  • Functional: Does it work as specified?
  • Non-functional: Performance, security, usability.
• Example:
  • eSewa’s load test: Can it handle 10,000 simultaneous transactions during Dashain?

D. Acceptance Testing

• What? Validated by the client/user.
• Types:
  • Alpha: Tested in developer’s environment.
  • Beta: Tested by real users (e.g., Pathao’s beta testers).
  • UAT (User Acceptance Testing): Final sign-off.

4. Test Strategies: How to Design Tests

A. Black-Box vs. White-Box vs. Grey-Box Testing

B. Test Design Techniques

1. Equivalence Partitioning:

   • Divide inputs into valid/invalid groups.
   • Example: For Daraz’s age verification, test:
     • Valid: 18, 30, 60.
     • Invalid: 17, 0, 100.

2. Boundary Value Analysis:

   • Test edge cases (max/min values).
   • Example: Ncell’s data limit (999MB vs. 1000MB).

3. Cause-Effect Graphing:

   • Map inputs to outputs logically.
   • Example: eSewa’s failed transaction → Check if it’s due to low balance OR network error.

5. Software Configuration Management (SCM): Controlling Chaos

SCM ensures consistency, traceability, and control over evolving software. Key concepts:

A. Configuration Items (CIs)

• What? Files, documents, or modules tracked by SCM.
• Examples:
  • Source code (main.py).
  • Design docs (requirements.pdf).
  • Binaries (eSewa.apk).

B. Baselines

• What? A snapshot of approved CIs at a point in time.
• Why? Prevents regression (e.g., Nepal Rastra Bank’s core system must not break after updates).
• Example:
  • Version 1.0 of Pathao’s app is baselined before Dashain sales.

C. Version Control

• Tools: Git, SVN, Mercurial.
• Commands:
  • git commit → Save changes.
  • git merge → Combine branches.
  • git tag v1.0 → Mark a release.
• Example:
  • Daraz’s team uses Git to track changes to the search algorithm before deploying.

D. Change Control

• Process:
  1. Request change (e.g., fix a bug in Khalti’s OTP system).
  2. Review impact (does it break other features?).
  3. Approve/reject.
  4. Implement & test.
  5. Release.
• Tools: JIRA, Trello, GitHub Issues.

Branching, merging, and tagging in Git (Image: TheresNoTime, CC BY-SA 4.0, via Wikimedia Commons)

6. SQA Plan: Your Battle Plan

An SQA Plan documents:

• Scope: What’s tested?
• Resources: Tools, team, budget.
• Schedule: Milestones (e.g., unit tests by Week 3).
• Roles: QA engineer, developer, tester.
• Metrics: Defect density, test coverage.

Example for eSewa’s New Feature:

7. Real-World Applications

A. eSewa: Quality in Financial Transactions

• Problem: A single bug in 2021 caused Rs. 200M in incorrect deductions.
• Solution:
  • Automated regression tests for payment flows.
  • SCM to track changes to the transaction module.
  • Load testing before Dashain (peak usage).

B. Daraz: Testing at Scale

• Challenge: 10,000+ orders/minute during sales.
• SQA Approach:
  • Stress testing the cart system.
  • A/B testing for UI changes (e.g., new checkout button).
  • SCM to roll back if a new algorithm causes crashes.

C. Ncell: Network Reliability

• Risk: Network outages during events (e.g., Tihar).
• SQA Measures:
  • System testing for call drop rates.
  • SCM to manage firmware updates without downtime.
  • User acceptance testing with beta users in Kathmandu.

Exam Tip: How to Score Full Marks

1. Define Clearly:
   • Always start with definitions (e.g., "Software Quality Assurance is a systematic approach to ensure software meets quality standards through processes like reviews, testing, and metrics.").
2. Use Examples:
   • Link concepts to Nepali apps/companies (e.g., "Like how Daraz uses integration testing to ensure the cart and payment modules work together").
3. Diagrams > Text:
   • Draw testing levels, SCM workflows, or Git branches in exams.
   • Mermaid tip: Use graph TD for processes, erDiagram for SCM tracking.
4. Compare Tables:
   • For verification vs. validation, black-box vs. white-box, or SCM tools, use tables.
5. Real Scenarios:
   • Examiners love worked examples. Practice:
     • "How would you test eSewa’s new fingerprint login?"
     • "What SCM steps would you take for Pathao’s app update?"
6. Avoid Vague Answers:
   • ❌ "Testing is important."
   • ✅ "Unit testing catches 80% of bugs early (e.g., Daraz’s search algorithm errors), reducing integration costs by 30%."

Final Checklist for Exam Day

• Quality factors: List 6 (correctness, reliability, etc.) with one Nepal example each.
• Verification vs. Validation: Define + one real-world fail case (e.g., Khalti’s OTP bug).
• Testing levels: Draw the 4-level pyramid (unit → acceptance) with one app example per level.
• SCM: Explain baselines, version control, and change control using Git/Daraz.
• SQA Plan: Outline 4 key sections (scope, resources, schedule, metrics).