# Best Practices ในกระบวนการทำ Software Testing

---

## 1. การวางแผนการทดสอบ (Test Planning)

### Best Practice 1 — เริ่มต้นจากการวิเคราะห์ความต้องการ ไม่ใช่จากโค้ด

การทดสอบที่ดีต้องเริ่มต้นจากการทำความเข้าใจ **Software Requirements Specification (SRS)** ก่อนเสมอ เพื่อให้รู้ว่าระบบควรทำอะไร มีฟังก์ชันหลักอะไรบ้าง และมีกฎธุรกิจอะไรที่สำคัญ ก่อนที่จะออกแบบ test case ใด ๆ

**หลักการที่สอดคล้อง:**

- **Requirements-based Testing** — test case ทุกตัวต้องสามารถ trace กลับไปยัง requirement ได้
- **V-Model** — การทดสอบมีคู่กับแต่ละระยะของการพัฒนา ตั้งแต่ Requirements → Unit Test, Design → Integration Test, System Spec → System Test

---

### Best Practice 2 — ใช้ Risk-Based Testing จัดลำดับความสำคัญ

ไม่มีเวลาทดสอบทุกอย่างได้ 100% ดังนั้นต้องระบุพื้นที่ความเสี่ยงสูงก่อน แล้วทุ่มความพยายามในการทดสอบตามลำดับความสำคัญ

**หลักการที่สอดคล้อง:**

- **Risk Matrix** — คำนวณ Risk Score = Probability × Impact แบ่งเป็น High (15–25), Medium (6–14), Low (1–5)
- ทดสอบ High Risk ก่อนเสมอ เช่น Authentication, Financial Calculation, Data Integrity

```
ตัวอย่าง Risk Matrix:
| พื้นที่           | Probability | Impact | Risk Score | Priority |
|------------------|-------------|--------|------------|----------|
| Login/Auth       |      4      |   5    |     20     |   สูง    |
| Book Search      |      3      |   2    |      6     | ปานกลาง |
| UI Styling       |      2      |   1    |      2     |   ต่ำ    |
```

---

### Best Practice 3 — เขียน Test Plan ก่อนเริ่มทดสอบเสมอ

Test Plan ที่ดีต้องกำหนดขอบเขต (scope), วิธีการ, ทรัพยากร, ตารางเวลา, เกณฑ์เข้า-ออก และความเสี่ยงที่อาจเกิดขึ้น ทำให้ทุกคนในทีมเข้าใจตรงกัน

**หลักการที่สอดคล้อง:**

- **IEEE 829 Standard** — มาตรฐานเอกสาร Test Plan ที่ใช้กันทั่วอุตสาหกรรม
- Test Plan ต้องระบุ: Entry Criteria (เมื่อไรเริ่มได้), Exit Criteria (เมื่อไรหยุดได้), Suspension Criteria (เมื่อไรหยุดชั่วคราว)

---

## 2. การออกแบบ Test Cases (Test Design)

### Best Practice 4 — ใช้ Black Box Techniques ให้ครบทั้ง 3 เทคนิค

การออกแบบ test case ที่มีประสิทธิภาพต้องใช้เทคนิคผสมกัน ไม่ใช้เทคนิคเดียว เพราะแต่ละเทคนิคครอบคลุมกรณีที่ต่างกัน

**หลักการที่สอดคล้อง:**

**Equivalence Partitioning (EP)**
แบ่ง input domain ออกเป็น partition ที่มีพฤติกรรมเหมือนกัน ทดสอบเพียงค่าตัวแทนจากแต่ละ partition แทนที่จะทดสอบทุกค่า

```
ตัวอย่าง: ช่องอายุ (valid: 18–65)
- Valid partition: ทดสอบค่าหนึ่ง เช่น 30
- Invalid partition 1: ค่า < 18 เช่น 10
- Invalid partition 2: ค่า > 65 เช่น 80
- Invalid partition 3: ตัวอักษร เช่น "abc"
```

**Boundary Value Analysis (BVA)**
ทดสอบที่ขอบเขตของแต่ละ partition เพราะข้อผิดพลาดมักเกิด "ที่ขอบ" (off-by-one errors)

```
สูตร: BVA Cases = 4n + 1  (n = จำนวนตัวแปร)
ตัวอย่าง: อายุ 18–65
ทดสอบที่: 17, 18, 19 ... 64, 65, 66
```

**Decision Table Testing (DTT)**
ทดสอบการรวมกันของเงื่อนไขหลาย ๆ ตัวพร้อมกัน เหมาะกับ logic ที่ซับซ้อน

```
สูตร: จำนวน test cases = 2^(จำนวน conditions)
ตัวอย่าง: 3 conditions → 2³ = 8 combinations
```

---

### Best Practice 5 — ออกแบบ Test Case ให้มีทั้ง Positive และ Negative Tests

Test case ที่ดีต้องครอบคลุมทั้งกรณีที่ระบบควรทำงานได้ (happy path) และกรณีที่ระบบควรปฏิเสธหรือแสดง error (negative path) ในสัดส่วนที่สมดุล

**หลักการที่สอดคล้อง:**

- **Positive Testing** — ใส่ข้อมูลถูกต้องเพื่อยืนยันว่าระบบทำงานได้
- **Negative Testing** — ใส่ข้อมูลผิด ข้อมูลขอบเขต หรือข้อมูลโจมตีเพื่อตรวจสอบว่าระบบจัดการได้ถูกต้อง
- โดยทั่วไปสัดส่วนที่ดี คือ Positive ~40% : Negative ~60%

---

### Best Practice 6 — เขียน Test Case ให้ชัดเจน ทำซ้ำได้ ไม่คลุมเครือ

Test case ที่ดีต้องให้คนอื่นทดสอบแทนได้โดยไม่ต้องถามผู้เขียน ขั้นตอนต้องเฉพาะเจาะจง ผลที่คาดหวังต้องวัดได้

**หลักการที่สอดคล้อง:**

- Test case ต้องมีครบ 5 องค์ประกอบ: **TC ID, Precondition, Steps, Expected Result, Technique**
- ❌ ไม่ดี: "ทดสอบการ login"
- ดี: "ป้อน username: admin, password: Admin@123 → คลิก Login → คาดหวัง: redirect ไปหน้า Dashboard แสดงชื่อ admin"

---

## 3. การตรวจสอบโค้ด (Verification & Validation)

### Best Practice 7 — ทำ Code Review ก่อน Execute Testing เสมอ

การค้นหาข้อบกพร่องในโค้ดโดยตรง (Static Testing) ก่อนรันโปรแกรมช่วยประหยัดเวลาได้มากกว่าการรอให้ test ล้มเหลว เพราะต้นทุนการแก้บั๊กในระยะ code review ต่ำกว่าในระยะ testing มาก

**หลักการที่สอดคล้อง:**

- **Verification** — "Are we building the product right?" ตรวจสอบว่าสร้างถูกต้องตาม spec หรือไม่
- **Validation** — "Are we building the right product?" ตรวจสอบว่าสร้างสิ่งที่ user ต้องการหรือไม่
- **Inspection Checklist** — ตรวจสอบอย่างเป็นระบบ ครอบคลุม Readability, Functionality, Error Handling, Security, Performance, Testing

```
ประเด็นสำคัญใน Code Review:
🔴 Security   — SQL Injection? Input validation? Password hashing?
🟠 Error Handling — จัดการ exception? ข้อความ error มีความหมาย?
🟡 Performance — มี nested loop ไม่จำเป็น? Query optimize แล้ว?
🟢 Readability — ชื่อตัวแปรสื่อความหมาย? มี comment อธิบาย?
```

---

### Best Practice 8 — วัด Code Coverage และตั้งเป้าหมายที่สมจริง

Coverage ช่วยระบุส่วนของโค้ดที่ยังไม่ถูกทดสอบ แต่ต้องเลือก level ที่เหมาะสมกับความเสี่ยงของระบบ

**หลักการที่สอดคล้อง:**

- **Statement Coverage (C0)** — ทุกบรรทัดถูก execute: เป้าหมาย ≥ 80%
- **Branch Coverage (C1)** — ทุก if/else ถูกทดสอบทั้งสองทาง: เป้าหมาย ≥ 70%
- **Path Coverage** — ทุกเส้นทางการทำงาน: ใช้กับ safety-critical systems
- ⚠️ **สำคัญ:** Coverage 100% ≠ ไม่มีบั๊ก — coverage สูงแต่ test data ไม่ดีก็ยังพลาดบั๊กได้

```
สูตรคำนวณ:
Statement Coverage = (บรรทัดที่ถูก execute / บรรทัดทั้งหมด) × 100%
Branch Coverage   = (สาขาที่ถูกทดสอบ / สาขาทั้งหมด) × 100%
```

---

## 4. การรันการทดสอบ (Test Execution)

### Best Practice 9 — บันทึกผลทดสอบทันทีและอย่างละเอียด

ขณะทดสอบต้องบันทึกผลจริงทุก test case ทันทีที่ทดสอบ อย่ารอให้เสร็จหมดแล้วค่อยบันทึก เพราะความจำไม่แม่นยำและอาจทำให้ข้อมูลคลาดเคลื่อน

**หลักการที่สอดคล้อง:**

- บันทึก Status ทั้ง 3: **Pass** (ทำงานตาม expected), **Fail** (ไม่ตรง expected), **Blocked** (ทดสอบไม่ได้เพราะติดปัญหาอื่น)
- เมื่อ test ล้มเหลวต้องบันทึกทันที: ขั้นตอนที่ทำ, ผลที่เกิดขึ้นจริง, ภาพหน้าจอ, สภาพแวดล้อม
- ติดตาม metrics ต่อเนื่อง: **Test Execution Rate = (executed / total) × 100%**, **Pass Rate = (pass / executed) × 100%**

---

### Best Practice 10 — จัดการ Test Environment ให้แยกจาก Production

สภาพแวดล้อมทดสอบที่ปนกับ production ทำให้ผลทดสอบไม่น่าเชื่อถือและอาจทำให้ข้อมูลจริงเสียหาย

**หลักการที่สอดคล้อง:**

- แยก Environment ชัดเจน: Dev → Test/QA → Staging → Production
- ใช้ข้อมูลทดสอบ (test data) ที่สร้างขึ้นมาโดยเฉพาะ ไม่ใช้ข้อมูลจริง
- ตั้งค่า Environment ให้ใกล้เคียง production มากที่สุดเพื่อความน่าเชื่อถือของผล

---

## 5. การจัดการข้อบกพร่อง (Defect Management)

### Best Practice 11 — เขียนรายงานบั๊กให้ทำซ้ำได้ทุกครั้ง

รายงานบั๊กที่ดีต้องให้นักพัฒนาสามารถทำซ้ำปัญหาได้เองโดยไม่ต้องถามผู้ทดสอบ ข้อมูลไม่ครบทำให้เสียเวลาและอาจทำให้บั๊กถูกปิดโดยไม่ได้แก้จริง

**หลักการที่สอดคล้อง:**

- รายงานบั๊กมาตรฐานต้องมี: **ID, ชื่อ (สั้น ชัด), ขั้นตอนทำซ้ำ, Expected Result, Actual Result, Severity, ภาพหน้าจอ, สภาพแวดล้อม**
- แยก **Severity** (ความรุนแรงทางเทคนิค) ออกจาก **Priority** (ความเร่งด่วนทางธุรกิจ) เพราะไม่ใช่สิ่งเดียวกัน

```
Severity Scale:
🔴 Critical — Crash, Data Loss, Security Breach
🟠 High    — Major function ใช้ไม่ได้
🟡 Medium  — Function ใช้ได้แต่ไม่สะดวก
🟢 Low     — Cosmetic issue ไม่กระทบการใช้งาน
```

---

### Best Practice 12 — วิเคราะห์สาเหตุรากเหง้า (Root Cause Analysis)

การแก้บั๊กโดยไม่รู้สาเหตุจริง ๆ มักทำให้บั๊กกลับมาซ้ำหรือเกิดบั๊กใหม่จากการแก้ไข การหาสาเหตุรากเหง้าช่วยป้องกันการเกิดซ้ำในระยะยาว

**หลักการที่สอดคล้อง:**

- **Root Cause Analysis (RCA)** — จำแนกสาเหตุเป็น 4 ประเภท: Programming Error, Design Issue, Missing Requirement, Environment Problem
- **5 Whys Technique** — ถาม "ทำไม" ซ้ำ 5 รอบเพื่อเจาะลึกถึงสาเหตุแท้จริง
- บั๊กที่มีสาเหตุเดียวกันควรแก้ไขพร้อมกันทั้งหมด ไม่แก้แยกทีละตัว

---

### Best Practice 13 — ติดตาม Bug Lifecycle ให้ครบทุกขั้นตอน

บั๊กที่ถูก "ปิด" โดยไม่ผ่านการ verify จากผู้ทดสอบ อาจเป็นบั๊กที่ยังไม่ได้แก้จริง ทุกบั๊กต้องผ่านกระบวนการยืนยันก่อนปิด

**หลักการที่สอดคล้อง:**

- **Bug Lifecycle:** New → Assigned → In Progress → Fixed → Verified → Closed (หรือ Reopen ถ้ายังมีปัญหา)
- ผู้ทดสอบ (ไม่ใช่นักพัฒนา) เป็นคนปิดบั๊ก หลังจาก verify ว่าแก้แล้วจริง
- ใช้ **Bug Tracking System** (GitHub Issues, Jira) เพื่อให้มี audit trail ครบถ้วน

---

## 6. Version Control และความร่วมมือในทีม

### Best Practice 14 — ใช้ Branch Strategy ที่ชัดเจนสำหรับการแก้บั๊ก

การแก้บั๊กบน main branch โดยตรงเป็นความเสี่ยงสูง ควรสร้าง branch แยกต่างหากสำหรับแต่ละ issue เพื่อให้ review และ revert ได้ง่าย

**หลักการที่สอดคล้อง:**

- **Feature Branch Workflow** — สร้าง branch ต่อ 1 issue เช่น `fix/login-validation`, `fix/search-performance`
- **Commit Message Convention** — ข้อความ commit ต้องชัดเจน: `Fix SQL injection in login form (#001)` ไม่ใช่ `update code`
- **Pull Request (PR) Review** — ทุก fix ต้องผ่าน PR และ code review ก่อน merge เสมอ
- **Link Commit ↔ Issue** — ทุก commit ควรอ้างอิง issue ID เพื่อ traceability

---

## 7. การทดสอบขั้นสูง (Advanced Testing)

### Best Practice 15 — ทดสอบ API ในทุก Scenario รวมถึง Error Cases

การทดสอบ API ที่ดีต้องไม่ทดสอบแค่ happy path แต่ต้องครอบคลุม error handling, authentication, authorization และ edge cases ด้วย

**หลักการที่สอดคล้อง:**

- ทดสอบ **HTTP Methods** ครบ: GET, POST, PUT, DELETE, PATCH
- ทดสอบ **Status Code** ที่หลากหลาย: 200, 201, 400, 401, 403, 404, 500
- ใช้ **Postman Collections** จัดกลุ่ม test และเขียน test script สำหรับ automated assertion
- ทดสอบ **End-to-End Scenario** เช่น Register → Login → Borrow → Return เพื่อยืนยัน data consistency

```
ตัวอย่าง Postman Test Script:
pm.test("Status 200", () => pm.response.to.have.status(200));
pm.test("Has data array", () => pm.expect(pm.response.json().data).to.be.an('array'));
pm.test("Response < 1s", () => pm.expect(pm.response.responseTime).to.be.below(1000));
```

---

### Best Practice 16 — ทดสอบความปลอดภัยด้วย OWASP Top 10 เป็นกรอบ

Security testing ต้องมีโครงสร้าง ไม่ใช่ทดสอบแบบสุ่ม การใช้ OWASP Top 10 เป็นกรอบช่วยให้ครอบคลุมช่องโหว่ที่พบบ่อยที่สุดในอุตสาหกรรม

**หลักการที่สอดคล้อง:**

- **OWASP Top 10** — มาตรฐาน Security Testing ที่ใช้กันทั่วโลก ครอบคลุม Injection, Broken Auth, XSS, CSRF, Misconfiguration ฯลฯ
- **Input Validation Testing** — ทดสอบ SQL Injection (`' OR '1'='1`), XSS (`<script>alert('xss')</script>`), Path Traversal
- **Authentication Testing** — ทดสอบ weak password, session timeout, account lockout, login bypass
- **Authorization Testing (RBAC)** — ยืนยันว่า user แต่ละ role เข้าถึงได้เฉพาะสิ่งที่อนุญาต

```
Security Testing Checklist:
☐ SQL Injection ใน input ทุกช่อง
☐ XSS ใน textarea, comment, search
☐ Login bypass ด้วย special characters
☐ Weak password ยอมรับหรือไม่
☐ Student เข้า admin panel ได้หรือไม่
☐ Password เก็บแบบ hash (bcrypt) ไม่ใช่ plain text
☐ Cookie มี Secure + HttpOnly flags
```

---

## 8. การวัดและรายงานคุณภาพ (Quality Metrics & Reporting)

### Best Practice 17 — ใช้ Metrics หลายตัวประกอบกัน อย่าตัดสินจาก Metric เดียว

Metric แต่ละตัวให้มุมมองที่ต่างกัน การใช้เพียงตัวเดียวอาจให้ภาพที่บิดเบือน เช่น Pass Rate 100% อาจเกิดจาก test case น้อยหรือไม่ดี ไม่ใช่ระบบดีจริง

**หลักการที่สอดคล้อง:**

- **Test Metrics:** Coverage %, Execution Rate, Pass Rate, Defect Detection Rate
- **Product Metrics:** Defect Density (บั๊ก/KLOC), Severity Distribution, Fix Ratio
- **Process Metrics:** Effort (ชั่วโมง), Schedule Adherence, Team Productivity

```
สูตรสำคัญ:
Defect Density        = จำนวนบั๊ก / (LOC / 1000)
Test Pass Rate        = (Passed / Executed) × 100%
Fix Effectiveness     = (Fixed / Found) × 100%
Regression Rate       = (Re-introduced / Total Fixed) × 100%
Test Case Effectiveness = Defects Found / Test Cases Executed
```

---

### Best Practice 18 — ประเมินคุณภาพด้วย ISO 25010 ครบ 8 มิติ

การรายงานคุณภาพที่สมบูรณ์ต้องไม่พูดแค่จำนวนบั๊ก แต่ต้องประเมินระบบในมิติที่ครอบคลุมตามมาตรฐานสากล

**หลักการที่สอดคล้อง:**

- **ISO/IEC 25010** — กรอบประเมินคุณภาพ 8 มิติ: Functionality, Reliability, Usability, Performance, Security, Maintainability, Compatibility, Portability
- แต่ละมิติต้องมีเกณฑ์วัดและ test evidence ประกอบ
- รายงานสุดท้ายต้องสรุป Go/No-Go decision พร้อมเหตุผลที่ชัดเจน

---

## 9. Automation Testing

### Best Practice 19 — เขียน Automated Test สำหรับ regression เป็นหลัก

Automated test มีต้นทุนสูงในการเขียน แต่คุ้มค่าสำหรับ test ที่ต้องรันซ้ำบ่อย โดยเฉพาะ regression testing หลังการแก้บั๊กหรือเพิ่มฟีเจอร์

**หลักการที่สอดคล้อง:**

- เน้น automate เฉพาะ **Regression Tests** และ **Critical Path Tests** ก่อน
- ใช้ **Test-Driven Development (TDD)** — เขียน test ก่อน แล้วค่อยเขียนโค้ดให้ผ่าน
- เป้าหมาย Coverage สำหรับ automation: Statement Coverage ≥ 80%, Branch Coverage ≥ 70%
- **PHPUnit** (สำหรับ PHP): ใช้ assertion ที่ชัดเจน assertEquals, assertTrue, assertThrows

```php
// ตัวอย่าง PHPUnit ที่ดี
public function testCalculateLateFee_ZeroDays_ReturnsZero() {
    $member = new Member();
    $this->assertEquals(0, $member->calculateLateFee(0));
}

public function testCalculateLateFee_ExceedsMax_ReturnsCapped() {
    $member = new Member();
    $this->assertEquals(1000, $member->calculateLateFee(100)); // max = 1000
}
```

---

## 10. หลักการสำคัญที่ควรจำตลอดกระบวนการ

### Best Practice 20 — Testing ไม่สามารถพิสูจน์ว่าซอฟต์แวร์ไม่มีบั๊ก

Testing พิสูจน์ได้เพียงว่า "พบบั๊ก" หรือ "ไม่พบบั๊กใน test ที่รัน" เท่านั้น การหยุดทดสอบเมื่อไม่พบบั๊กใหม่ไม่ได้หมายความว่าระบบสมบูรณ์แล้ว

**หลักการที่สอดคล้อง:**

- **Dijkstra's Principle** — "Testing can show the presence of bugs, not their absence"
- ใช้ **Risk-Based Approach** ตัดสินใจหยุดทดสอบ ไม่ใช่รอให้ไม่มีบั๊กเลย
- **Exit Criteria** ที่ดี เช่น "Critical bugs = 0, High bugs ≤ 2, Pass Rate ≥ 95%, Coverage ≥ 80%"

---

### Best Practice 21 — ทดสอบเร็ว (Shift Left Testing)

ยิ่งพบบั๊กช้า ต้นทุนในการแก้ยิ่งสูง บั๊กที่พบตอน Requirements ใช้ต้นทุนแก้น้อยกว่าบั๊กที่พบตอน Production มากถึง 100 เท่า

**หลักการที่สอดคล้อง:**

- **Shift-Left Testing** — เริ่ม testing activities ตั้งแต่ระยะ Requirements และ Design
- Code Review → Unit Test → Integration Test → System Test → UAT (ตามลำดับ ไม่ข้าม)
- Cost of fixing: Requirements (1×) < Design (5×) < Coding (10×) < Testing (20×) < Production (100×)

---

### Best Practice 22 — แยกบทบาท Developer และ Tester ออกจากกัน

นักพัฒนาไม่ควรทดสอบโค้ดของตัวเองเพราะมี bias — มักทดสอบในแบบที่รู้ว่าจะผ่าน ไม่ใช่แบบที่จะค้นหาบั๊ก

**หลักการที่สอดคล้อง:**

- **Independence of Testing** — ผู้ทดสอบที่ดีที่สุดคือคนที่ไม่ได้เขียนโค้ดนั้น
- อย่างน้อยต้องมี Peer Review — ให้เพื่อนร่วมทีม review code ก่อนทุกครั้ง
- ใน team project: Test Manager ควรติดตามและยืนยันผลลัพธ์อย่างเป็นอิสระ

---

## สรุป — แผนภาพกระบวนการ

```
Requirements Analysis
        ↓
  [Best Practice 1] อ่าน SRS ก่อนทุกครั้ง
        ↓
Risk Assessment
        ↓
  [Best Practice 2] สร้าง Risk Matrix
        ↓
Test Planning
        ↓
  [Best Practice 3] เขียน Test Plan (IEEE 829)
        ↓
Test Design
        ↓
  [Best Practice 4, 5, 6] EP + BVA + DTT, Positive + Negative, ชัดเจน
        ↓
Code Review / V&V
        ↓
  [Best Practice 7, 8] Inspection Checklist, Coverage Target
        ↓
Test Execution
        ↓
  [Best Practice 9, 10] บันทึกทันที, แยก Environment
        ↓
Defect Management
        ↓
  [Best Practice 11, 12, 13] รายงานบั๊กดี, RCA, Bug Lifecycle
        ↓
Version Control
        ↓
  [Best Practice 14] Branch Strategy, PR Review
        ↓
Advanced Testing
        ↓
  [Best Practice 15, 16] API Testing, Security (OWASP)
        ↓
Automation (Optional)
        ↓
  [Best Practice 19] TDD, Regression Automation
        ↓
Quality Reporting
        ↓
  [Best Practice 17, 18] Multiple Metrics, ISO 25010
        ↓
Go / No-Go Decision
```

---