အခန်း ၁၁ :: Software Quality Assurance (SQA)

Software Quality Assurance (SQA) ဆိုသည်မှာ ကားမောင်းမထွက်ခင် "လမ်းကြောင်း မှန်ရဲ့လား"၊ "ဘရိတ်ကောင်းရဲ့လား"၊ "ယာဉ်မောင်းမှာ လိုင်စင်ရှိရဲ့လား" ဟု ကြိုတင် စစ်ဆေးပြီး လမ်းညွှန်ပေးသော လုပ်ငန်းစဉ်နှင့် တူပါသည်။ SQA ၏ အဓိက ရည်မှန်းချက်မှာ Defect များကို ရှာဖွေရန် (Find) သက်သက် မဟုတ်ဘဲ၊ Defect များ မဖြစ်ပေါ်လာအောင် ကာကွယ်ရန် (Prevent) ဖြစ်သည်။

၁၁.၁ QA vs. QC (QA နှင့် QC မတူပါ)

Developer အများစုသည် SQA (Software Quality Assurance) နှင့် QC (Quality Control) ကို ရောထွေး မှားယွင်းတတ်ကြသည်။ ဤနှစ်ခုသည် ရည်ရွယ်ချက်ရော လုပ်ဆောင်ပုံပါ ကွာခြားပါသည်။

1. Quality Assurance (QA) - "Process Focus"

• သဘောတရား - ကြိုတင်ကာကွယ်သော (Proactive) ချဉ်းကပ်မှု ဖြစ်သည်။

• မေးခွန်း - "ငါတို့ အလုပ်လုပ်နေတဲ့ နည်းလမ်း (Process) မှန်ရဲ့လား"

• ဥပမာ - Coding Standard သတ်မှတ်ခြင်း၊ Code Review Checklist ပြင်ဆင်ခြင်း၊ Training ပေးခြင်း၊ CI/CD Pipeline တည်ဆောက်ခြင်း။

2. Quality Control (QC) - "Product Focus"

• သဘောတရား - ပြဿနာဖြစ်မှ ဖြေရှင်းသော (Reactive) ချဉ်းကပ်မှု ဖြစ်သည်။

• မေးခွန်း - "ထွက်လာတဲ့ Product က မှန်ရဲ့လား"

• ဥပမာ - Testing လုပ်ခြင်း၊ Bug ရှာဖွေခြင်း၊ Inspection လုပ်ခြင်း။

graph TD
subgraph "Quality Management"
QA["<b>SQA (Assurance)</b><br/>Process Focused<br/><i>Prevention</i>"]
QC["<b>QC (Control)</b><br/>Product Focused<br/><i>Detection</i>"]
end

QA -->|Sets Standards| Process[Development Process]
Process -->|Produces| Software
QC -->|Finds Bugs| Software
QC -.->|Feedback| QA

style QA fill:#e1f5fe,stroke:#01579b
style QC fill:#ffebee,stroke:#b71c1c

Key Takeaway: Company အများစုတွင် “QA Engineer” ဟု ခေါ်လေ့ရှိသော်လည်း လက်တွေ့ လုပ်နေရသည်မှာ Manual Testing + Bug Reporting (QC) သာ ဖြစ်နေတတ်သည်။ တကယ့် QA ဆိုသည်မှာ Process design၊ Quality gates၊ Automation strategy နှင့် Metrics definition များကိုပါ ဆုံးဖြတ်နိုင်သူ ဖြစ်ရပါမည်။

၁၁.၂ Quality Management Systems (QMS) & Automation

Software Development Team တစ်ခုတွင် အရည်အသွေး ကောင်းမွန်စေရန် လူတစ်ယောက်တည်း (Hero) ကောင်းနေရုံဖြင့် မရပါ။ စနစ် (System) ကောင်းရန် လိုအပ်ပါသည်။ ဤစနစ်ကို Quality Management System (QMS) ဟု ခေါ်သည်။

Practical QA: Automation Strategy

Project တစ်ခု မစခင် SQA Plan တစ်ခု ရေးဆွဲရာတွင် အောက်ပါအချက်များ ပါဝင်ရပါမည် -

1. ဘယ် Coding Standard ကို သုံးမလဲ (ဥပမာ - Google Java Style Guide)။

2. Code Review ကို ဘယ်လို လုပ်မလဲ (Github PR သုံးမလား၊ Pair Programming သုံးမလား)။

3. Bug တွေ့ရင် ဘယ်လို မှတ်တမ်းတင်မလဲ (Jira Workflow)။

Company အများစုသည် SQA Plan ကို စာရွက်ပေါ်တွင်သာ မထားဘဲ Automation ပုံစံဖြင့် အကောင်အထည် ဖော်လာကြသည်။ လူတစ်ယောက်ချင်းစီကို "စည်းကမ်းလိုက်နာပါ" ဟု လိုက်ပြောနေမည့်အစား Tool များကို အသုံးပြု၍ ထိန်းချုပ်ခြင်း ဖြစ်သည်။

Local Environment Automation (Git Hooks)

Git Commit မလုပ်ခင် (သို့) Push မလုပ်ခင် အလိုအလျောက် စစ်ဆေးသည့် စနစ်များ ထားရှိသင့်သည်။

• .git/hooks/pre-commit: Commit မလုပ်ခင် Coding Standard (Lint) စစ်ဆေးခြင်း၊ Secret Key များ ပါမပါ စစ်ဆေးခြင်း။

• .git/hooks/pre-push: Code များကို Server ပေါ် မတင်ခင် Unit Test များ Run ခြင်း။

• Tool: Shell script များ ကိုယ်တိုင်ရေးမည့်အစား NodeJS project များအတွက် Husky ကဲ့သို့သော library များကို အသုံးပြုနိုင်သည်။

CI/CD Automation (Github Actions)

Developer စက် (Local) တွင် စစ်ဆေးပြီးသော်လည်း၊ Server ပေါ်ရောက်သည့်အခါ ထပ်မံ စစ်ဆေးရန် လိုအပ်သည်။

• Branch ပေါ်မူတည်ပြီး Auto Deployment လုပ်ခြင်း။

• Pull Request တင်သည်နှင့် Unit Test, Lint တို့ကို အလိုအလျောက် Run ခြင်း။

Note: QA အဆင့်သည် လူကို အားကိုးခြင်းထက် စနစ် (System) ကို တည်ဆောက်ထားရန် လိုအပ်သည်။ Automation သည် အကောင်းဆုံး Quality Gate ဖြစ်သည်။

၁၁.၃ Core QA Metrics (ဘာတွေကို တိုင်းတာသင့်သလဲ)

“Quality” ဆိုတာ ခံစားချက် (Feeling) မဟုတ်ပါ။ တိုင်းတာနိုင်ရမည့် အချက်အလက် (Metrics) ဖြစ်ပါသည်။ မတိုင်းတာနိုင်ရင် မထိန်းချုပ်နိုင်ပါ။

QA Metrics များကို အောက်ပါ အုပ်စု ၃ ခုအဖြစ် ခွဲနိုင်ပါသည်။

(A) Process Metrics (QA / Engineering Flow)

ဒီ Metrics များသည် Team အလုပ်လုပ်ပုံ ကောင်းမကောင်း ကို ပြသပါသည်။

• Code Review Turnaround Time: Pull Request တစ်ခုကို Review ပြီးဖို့ ဘယ်လောက်ကြာသလဲ။ (ကြာလွန်းရင် Delivery နှေးကွေးမှု ရှိနေသည်)။

• PR Rejection Rate: Review မှာ Reject ဖြစ်တဲ့ PR အချိုးအစား။ (မြင့်လွန်းရင် Coding Standard သို့မဟုတ် Requirement မရှင်းလင်းမှု ရှိနေနိုင်သည်)။

• Automation Gate Pass Rate: CI Pipeline မှာ Test, Lint, Build တို့ကို တစ်ခါတည်း Pass ဖြစ်တဲ့ အချိုးအစား။ (Quality Gate များ အလုပ်လုပ်မလုပ်ကို ပြသသည်)။

(B) Product Quality Metrics (QC / Outcome)

ဒီ Metrics များသည် ထွက်လာတဲ့ Software အရည်အသွေး ကို ပြသပါသည်။

• Defect Density: Code အရွယ်အစား (KLOC) တစ်ခုစီအတွက် Bug ဘယ်နှခု ထွက်သလဲ။

• Escaped Defects: QA Environment မှာ မတွေ့ဘဲ Production မှာမှ တွေ့ရတဲ့ Bug အရေအတွက်။ (QA Effectiveness ကို တိုက်ရိုက်ပြသသည်)။

• Regression Failure Rate: Feature အသစ်ထည့်ပြီးနောက် အဟောင်း Feature ပျက်သွားတဲ့ အကြိမ်ရေ။ (Automation Coverage မလုံလောက်မှုကို ပြသသည်)။

(C) DevOps & Stability Metrics (System Health)

ဒီ Metrics များသည် Speed နှင့် Stability မျှတမှု ကို ပြသပါသည်။ ဤ Metrics များကို DORA Metrics ဟု ခေါ်ပြီး Level 4 (Quantitatively Managed) Team များအတွက် မဖြစ်မနေ လိုအပ်ပါသည်။

1. Deployment Frequency (ဘယ်လောက် မကြာခဏ Deploy လုပ်နိုင်သလဲ)

2. Lead Time for Changes (Idea မှ Production ရောက်ရန် ကြာချိန်)

3. Change Failure Rate (Deploy လုပ်တိုင်း Error တက်နှုန်း)

4. Mean Time to Restore (MTTR) (Error ဖြစ်လျှင် ပြန်ပြင်ရန် ကြာချိန်)

Key Insight:

Bug အရေအတွက် နည်းလာခြင်းထက် Bug မဖြစ်နိုင်တဲ့ Process ကို တည်ဆောက်နိုင်ခြင်း က ပိုအရေးကြီးသည်။ Metrics များသည် လူကို စောင့်ကြည့်ရန် မဟုတ်ဘဲ System ကို တိုးတက်အောင် ပြင်ရန် အသုံးပြုရပါသည်။

၁၁.၄ Modern Startup Engineering Maturity Model

Software Team တစ်ခု၏ ရင့်ကျက်မှုကို အောက်ပါအတိုင်း တိုင်းတာနိုင်ပါသည်။

Level 1: Initial (Hero Driven)

• Status: No CI/CD, Hero Dev.

• အခြေအနေ: Process မရှိ။ Developer တွေ တော်လို့သာ Project ပြီးသွားတာမျိုး။ Developer တစ်ယောက်၊ နှစ်ယောက်၏ စွမ်းဆောင်ရည်အပေါ် လုံးလုံးလျားလျား မှီခိုနေရသည်။

• Testing: Developer က ကိုယ့်စက်မှာ ကိုယ်စမ်းပြီး "အဆင်ပြေတယ်" ဆိုရင် ပြီးပြီ။

Level 2: Managed (Basic Tooling)

• Status: Jira + Basic CI.

• အခြေအနေ: Project တစ်ခုချင်းစီမှာ Plan ရှိလာပြီ။ Task တွေကို Jira/Trello ဖြင့် မှတ်တမ်းတင်သည်။ Code push လိုက်ရင် Build pass/fail လောက်စစ်ပေးသော Basic Automation ရှိလာသည်။

• Testing: Manual Tester (QC) ရှိလာနိုင်သော်လည်း၊ Development ပြီးမှသာ စစ်ဆေးလေ့ရှိသည်။

Level 3: Defined (Standardization)

• Status: Standard branching, code review, test strategy.

• အခြေအနေ: Team တစ်ခုလုံး လိုက်နာရမည့် Standard များ ရှိလာသည်။ Code Review သည် မဖြစ်မနေ လုပ်ရမည့် အဆင့် (Mandatory) ဖြစ်လာသည်။ Gitflow သို့မဟုတ် Trunk-based ကဲ့သို့ Branching Strategy ကို တိတိကျကျ သုံးသည်။

• Baseline: ဤအဆင့်သည် Professional Software Team တစ်ခု၏ "အနိမ့်ဆုံး စံနှုန်း" ဖြစ်သင့်ပါသည်။

Level 4: Quantitatively Managed (Metrics Driven)

• Status: Metrics (Deployment Frequency, Lead Time, Change Failure Rate).

• အခြေအနေ: အထက် (၁၁.၃) တွင် ဖော်ပြခဲ့သော Metrics များကို အသုံးပြုပြီး Data ဖြင့် စီမံခန့်ခွဲသည်။ Speed နှင့် Stability ကို မျှတအောင် ထိန်းညှိသည်။

Level 5: Optimizing (Continuous Improvement)

• Status: Continuous improvement + Root Cause Analysis (RCA) culture.

• အခြေအနေ: ပြဿနာ ဖြစ်ပွားမှုကို သင်ယူစရာ (Learning Opportunity) အဖြစ် ရှုမြင်သည်။ Blameless Post-mortems ယဉ်ကျေးမှု ထွန်းကားပြီး၊ Self-healing system များကို တည်ဆောက်သည်။

graph LR
L1["<b>Level 1</b>Hero Dev"] --> L2["<b>Level 2</b>Jira + Basic CI"]
L2 --> L3["<b>Level 3</b>Process + Strategy"]
L3 --> L4["<b>Level 4</b>Metrics (DORA)"]
L4 --> L5["<b>Level 5</b>RCA Culture"]

style L3 fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
style L4 fill:#bbdefb,stroke:#1976d2,stroke-width:2px
style L5 fill:#c8e6c9,stroke:#388e3c,stroke-width:2px

၁၁.၅ Practical QC: Testing Terminology

QC သည် Product ကို စစ်ဆေးခြင်း (Product Validation) ဖြစ်သည်။ "Testing လုပ်သည်" ဟု ယေဘုယျ ပြောလေ့ရှိသော်လည်း ရည်ရွယ်ချက်ပေါ် မူတည်၍ Testing အမျိုးအစား (Types) ကွဲပြားပါသည်။

၁. Functional Testing Types (လုပ်ဆောင်ချက်များကို စစ်ဆေးခြင်း)

(A) Smoke Testing (Build Verification Testing)

• Concept: "မီးခလုတ် ဖွင့်လိုက်ရင် မီးခိုးထွက်လာသလား"။ Software တစ်ခုလုံး၏ အရေးအကြီးဆုံး အစိတ်အပိုင်း (Critical Functionalities) တွေ အလုပ်လုပ်ရဲ့လား ဆိုတာကို အပေါ်ယံ စစ်ဆေးခြင်း ဖြစ်သည်။

• Scenario: Deployment လုပ်ပြီးပြီးချင်း Web Application ပွင့်မပွင့်၊ Login ဝင်လို့ရမရ၊ Database connect မိမမိ စစ်ဆေးခြင်း။

• Why: Login တောင် ဝင်မရတဲ့ Build တစ်ခုကို ဆက်ပြီး အသေးစိတ် Test လုပ်နေရင် အချိန်ကုန်တာပဲ အဖတ်တင်ပါလိမ့်မယ်။

(B) Sanity Testing

• Concept: Bug တစ်ခုကို ပြင်လိုက်ပြီးနောက် (သို့) Feature အသစ်တစ်ခု ထည့်ပြီးနောက်၊ ထိုပြင်လိုက်သော အပိုင်း တကယ် ကောင်းသွားပြီလား ဆိုတာကို ဇောက်ချ စစ်ဆေးခြင်း ဖြစ်သည်။

• Difference: Smoke Testing က တစ်ခုလုံးကို အပေါ်ယံ (Shallow and Wide) စစ်တာဖြစ်ပြီး၊ Sanity က ပြင်လိုက်တဲ့နေရာကို အသေးစိတ် (Narrow and Deep) စစ်တာ ဖြစ်သည်။

(C) Regression Testing

• Concept: ကုဒ်အသစ်တွေ ထပ်ထည့်လိုက်တာကြောင့်၊ အရင်ရှိပြီးသား Feature အဟောင်းတွေ ပျက်မသွားကြောင်း သေချာအောင် စစ်ဆေးခြင်း ဖြစ်သည်။

• Scenario: Payment function အသစ်ထည့်လိုက်တာကြောင့်၊ အရင်ရှိပြီးသား "Add to Cart" function အလုပ်မလုပ်တော့တာမျိုး မဖြစ်အောင် တားဆီးရန်။

• Note: Regression Testing သည် လူနှင့်စစ်လျှင် အချိန်အလွန်ကုန်သဖြင့် Automated Testing ကို အဓိက အားကိုးရသော နေရာဖြစ်သည်။

(D) User Acceptance Testing (UAT)

• Concept: Developer နှင့် Tester များ စစ်ဆေးပြီးသည့် Product ကို အမှန်တကယ် အသုံးပြုမည့် Client (သို့) End User ကိုယ်တိုင် လက်ခံနိုင်မှု ရှိမရှိ စမ်းသပ်ခြင်း ဖြစ်သည်။

(E) Observability Testing

• Error ဖြစ်ရင် Alert တက်မတက်၊ Logs တွေ မှန်မမှန် စစ်ဆေးခြင်း ဖြစ်သည်။

၂. Non-Functional Testing (စွမ်းဆောင်ရည်ကို စစ်ဆေးခြင်း)

Feature အလုပ်လုပ်ရုံဖြင့် မလုံလောက်ပါ။ System ၏ Behavior ကို စစ်ဆေးရန် လိုအပ်သည်။

• Load Testing: User အများကြီး (Expected Traffic) ဝင်လာရင် Server ခံနိုင်မလား။

• Stress Testing: System ရဲ့ Break point ကို သိချင်လို့ ကန့်သတ်ချက်ထက် ကျော်လွန်ပြီး ဒုက္ခပေး စမ်းသပ်ခြင်း။

• Security Testing: Vulnerabilities များ (SQL Injection, XSS) ရှိမရှိ စစ်ဆေးခြင်း။

၃. Testing Methods (စစ်ဆေးပုံ နည်းစနစ်များ)

• Black-box Testing: အတွင်းပိုင်း Code ကို မကြည့်ဘဲ၊ User အမြင်ဖြင့် Input ထည့်၊ Output ထွက်တာ မှန်မမှန် စစ်ဆေးခြင်း။

• White-box Testing: အတွင်းပိုင်း Logic, Branching, Code Structure များကို သိပြီး စစ်ဆေးခြင်း။ (Unit Testing ရေးသော Developer များ လုပ်သည်)။

၁၁.၆ Software Reviews and Audits

Code ရေးပြီးမှ စစ်ဆေးခြင်းထက်၊ မရေးခင် သို့မဟုတ် ရေးနေစဉ် စစ်ဆေးခြင်းက ကုန်ကျစရိတ် ပိုသက်သာသည်။

1. Software Reviews (Peer Reviews)

   • Walkthrough: ရေးထားတဲ့သူက ဦးဆောင်ပြီး ကျန်တဲ့သူတွေကို လိုက်ပြတာမျိုး။ (Knowledge Sharing သဘော ပိုဆန်သည်)။

   • Inspection: အသေးစိတ် စစ်ဆေးတာမျိုး။ (Code Review in Pull Request)။

2. Software Audits

   • ဒါကတော့ ကိုယ့် Team က လူ မဟုတ်ဘဲ၊ ပြင်ပ အဖွဲ့အစည်း (External Auditor) သို့မဟုတ် သီးခြား QA Team က လာရောက် စစ်ဆေးခြင်း ဖြစ်သည်။ (ဥပမာ - Security Compliance, GDPR စစ်ဆေးခြင်း)။

၁၁.၇ Defect Management

Bug တစ်ခု တွေ့ပြီဆိုရင် "တွေ့ပြီ၊ ပြင်လိုက်ပြီ" ဆိုပြီး ပြီးသွားလို့ မရပါ။ Defect Lifecycle တစ်ခု ရှိဖို့ လိုပါတယ်။

stateDiagram-v2
[*] --> New
New --> Open: Confirmed
Open --> Assigned: Dev Assigned
Assigned --> InProgress: Coding
InProgress --> Fixed: Dev Done
Fixed --> Verified: QA Pass
Verified --> Closed: Release
Fixed --> Reopened: QA Fail
Reopened --> Assigned
Open --> Rejected: Not a Bug
Open --> Deferred: Fix Later

• New: Bug စတွေ့တယ်။

• Open: Team Lead က Bug အစစ် ဟုတ်မဟုတ် စစ်ဆေးပြီး အတည်ပြုတယ်။

• Assigned: Developer တစ်ယောက်ကို တာဝန်ပေးတယ်။

• Fixed: Developer က ပြင်ပြီးပြီ။

• Verified: QA က ပြန်စစ်လို့ အဆင်ပြေတယ်။

• Reopened: QA က ပြန်စစ်တာ အဆင်မပြေသေးဘူး။ ပြန်ပြင်ခိုင်းတယ်။

၁၁.၈ Root Cause Analysis (RCA) - The "5 Whys"

SQA ၏ အနှစ်သာရသည် Bug ကို ပြင်ရုံ (Fixing) မဟုတ်ဘဲ၊ နောက်တစ်ခါ ထပ်မဖြစ်အောင် ကာကွယ်ခြင်း (Prevention) ဖြစ်သည်။ ထိုသို့ ကာကွယ်ရန် "5 Whys" နည်းလမ်းကို သုံး၍ အရင်းခံ အကြောင်းတရား (Root Cause) ကို ရှာဖွေရပါမည်။

Scenario: User တစ်ယောက် Checkout လုပ်တဲ့အခါ Error တက်နေသည်။

1. Why? System Crash ဖြစ်သွားလို့။ (Symptom)

   • Solution: Restart server. (Temporary Fix)

2. Why? user object က null ဖြစ်နေလို့။

   • Solution: Add null check.

3. Why? User Data ကို API ကနေ လှမ်းယူတာ မရလိုက်လို့။

4. Why? API Call က Network Timeout ဖြစ်သွားလို့။

5. Why? (Root Cause) API Client မှာ Network Failure ဖြစ်ရင် ပြန်စမ်းတဲ့ (Retry Mechanism) မပါလို့။

Action: Code ထဲမှာ Null check ထည့်ရုံနဲ့ မပြီးဘဲ၊ API Client Module တစ်ခုလုံးမှာ Retry Policy ထည့်သွင်းလိုက်မှသာ နောက်နောင် Network မကောင်းတဲ့အခါ Crash မဖြစ်တော့မှာ ဖြစ်ပါတယ်။ ဒါသည် SQA ၏ ချဉ်းကပ်ပုံ ဖြစ်ပါသည်။

Summary

Software Quality Assurance (SQA) သည် Tester တွေရဲ့ အလုပ် သက်သက် မဟုတ်ပါ။ Developer တိုင်း၊ Manager တိုင်း ပါဝင်ရမည့် Culture (ယဉ်ကျေးမှု) တစ်ခု ဖြစ်ပါသည်။

1. QC က Bug ရှာသည်၊ QA က Bug မဖြစ်အောင် Process တွေ ချမှတ်သည်။

2. Automation (Lint, Test, CI/CD) သည် အရည်အသွေးကို ထိန်းချုပ်မည့် Quality Gates များ ဖြစ်သည်။

3. Metrics (Process, Product, Stability) များကို တိုင်းတာပြီး Level 4 သို့ ရောက်အောင် ကြိုးစားပါ။

4. 5 Whys ကို သုံးပြီး ပြဿနာရဲ့ အမြစ်ကို ရှာပါ။

အရည်အသွေး ကောင်းမွန်သော Software ဆိုသည်မှာ ကံကောင်းလို့ ဖြစ်လာတာ မဟုတ်ဘဲ၊ စနစ်တကျ တည်ဆောက်ယူခြင်း (Engineering) ၏ ရလဒ် ဖြစ်ပါသည်။