# สัปดาห์ที่ 4: Requirements Analysis และ Test Case Design

## 📋 Learning Objectives
เมื่อจบสัปดาห์นี้ นักศึกษาจะสามารถ:
1. วิเคราะห์ Requirements เพื่อใช้ในการออกแบบ Test Cases
2. สร้าง Requirements Traceability Matrix (RTM)
3. เขียน Test Cases ที่มีคุณภาพตาม Best Practices
4. แยกแยะระหว่าง Positive และ Negative Test Cases
5. ใช้งาน Test Case Management Tools
6. จัดการ Test Data อย่างมีประสิทธิภาพ

---

## Part 1: Requirements Analysis for Testing (30 นาที)

### 1.1 ความสำคัญของ Requirements ต่อการทดสอบ

**"You can't test what you don't understand"**

Requirements คือรากฐานของการทดสอบทั้งหมด:
- **Good Requirements** → Easy to test, Clear criteria
- **Poor Requirements** → Ambiguous tests, Missed defects

### 1.2 Types of Requirements

#### 1. Functional Requirements (FR)
ระบุ **"ระบบต้องทำอะไร"**

**ตัวอย่าง Library System:**
```
FR-001: ระบบต้องให้ผู้ใช้ลงทะเบียนด้วย username, email และ password
FR-002: Username ต้องมีความยาว 4-20 ตัวอักษร
FR-003: Email ต้องอยู่ในรูปแบบที่ถูกต้อง (xxx@yyy.zzz)
FR-004: Password ต้องมีอย่างน้อย 8 ตัวอักษร
FR-005: ระบบต้องตรวจสอบว่า username ซ้ำหรือไม่
```

#### 2. Non-Functional Requirements (NFR)
ระบุ **"ระบบต้องทำงานอย่างไร"** (คุณภาพของระบบ)

**ตัวอย่าง:**
```
NFR-001: หน้า Login ต้องโหลดภายใน 2 วินาที
NFR-002: ระบบต้องรองรับผู้ใช้พร้อมกัน 100 คน
NFR-003: Password ต้องถูกเข้ารหัสด้วย bcrypt
NFR-004: ระบบต้องทำงานได้บน Chrome, Firefox, Safari
```

### 1.3 Characteristics of Good Requirements (SMART)

Good requirements ควรมีคุณสมบัติ:

| Characteristic | คำอธิบาย | ตัวอย่าง Bad | ตัวอย่าง Good |
|---------------|---------|-------------|--------------|
| **Specific** | ชัดเจน ไม่คลุมเครือ | "Password ต้องแข็งแรง" | "Password ต้องมีอย่างน้อย 8 ตัวอักษร รวมตัวเลขและอักขระพิเศษ" |
| **Measurable** | วัดได้ | "ระบบต้องเร็ว" | "Response time < 2 วินาที" |
| **Achievable** | ทำได้จริง | "ระบบต้องไม่มี bugs" | "Critical bugs < 5 ต่อ release" |
| **Relevant** | เกี่ยวข้องกับระบบ | "UI ต้องสวย" | "UI ต้อง responsive บน mobile" |
| **Testable** | ทดสอบได้ | "ระบบต้องใช้งานง่าย" | "ผู้ใช้ใหม่สามารถยืมหนังสือได้ภายใน 5 นาที" |

### 1.4 Requirements Analysis Process

```
1. Gather Requirements
   ↓
2. Review & Clarify (ถามคำถาม!)
   ↓
3. Identify Testable Items
   ↓
4. Define Test Conditions
   ↓
5. Design Test Cases
```

#### คำถามสำคัญที่ต้องถาม:

✅ **Positive Scenarios:**
- "อะไรคือการใช้งานที่ถูกต้อง?"
- "Expected output คืออะไร?"

✅ **Negative Scenarios:**
- "อะไรคือ Invalid inputs?"
- "ระบบต้อง handle errors อย่างไร?"

✅ **Edge Cases:**
- "Boundary values คืออะไร?"
- "Special cases มีอะไรบ้าง?"

✅ **Dependencies:**
- "มี prerequisites อะไรบ้าง?"
- "ต้องมีข้อมูลอะไรก่อน?"

---

## Part 2: Requirements Traceability Matrix (RTM) (20 นาที)

### 2.1 RTM คือ อะไร?

**Requirements Traceability Matrix (RTM)** คือเอกสารที่แสดงความเชื่อมโยงระหว่าง:
- **Requirements** ↔ **Test Cases** ↔ **Test Results**

### 2.2 วัตถุประสงค์ของ RTM

✅ ตรวจสอบว่าทุก requirement มี test cases ครบ (100% coverage)  
✅ ติดตาม test execution status  
✅ Impact analysis เมื่อมีการเปลี่ยนแปลง requirements  
✅ รายงานให้ stakeholders เห็นความคืบหน้า  

### 2.3 โครงสร้างของ RTM

**Basic RTM Format:**

| Req ID | Requirement Description | Test Case IDs | Priority | Status | Defect IDs |
|--------|------------------------|---------------|----------|--------|------------|
| FR-001 | User registration with username, email, password | TC-001, TC-002, TC-003 | High | Pass | - |
| FR-002 | Username 4-20 characters | TC-004, TC-005, TC-006 | High | Pass | - |
| FR-003 | Valid email format | TC-007, TC-008, TC-009 | High | Fail | BUG-042 |

**Advanced RTM with Coverage:**

| Req ID | Requirement | Positive TCs | Negative TCs | Edge TCs | Total TCs | Coverage |
|--------|-------------|--------------|--------------|----------|-----------|----------|
| FR-001 | User registration | 3 | 5 | 2 | 10 | 100% |
| FR-002 | Username validation | 2 | 4 | 2 | 8 | 100% |

### 2.4 Types of Traceability

1. **Forward Traceability:** Requirements → Test Cases → Test Results
2. **Backward Traceability:** Test Cases → Requirements (ตรวจสอบว่าทุก test case มาจาก requirement)
3. **Bidirectional Traceability:** ทั้งสองทิศทาง

### 2.5 RTM Best Practices

✅ Maintain เป็นประจำ (living document)  
✅ ใช้เครื่องมือ (Excel, Google Sheets, Test Management Tools)  
✅ Review ร่วมกับทีม  
✅ Update เมื่อมี requirement changes  
✅ Track defects ที่เจอ  

---

## Part 3: Test Case Design (30 นาที)

### 3.1 Test Case คือ อะไร?

**Test Case** = ชุดของเงื่อนไขและขั้นตอนที่ออกแบบมาเพื่อทดสอบ requirement หนึ่งๆ

### 3.2 Test Case Components

#### องค์ประกอบมาตรฐานของ Test Case:

```
1. Test Case ID          : Unique identifier (TC-001)
2. Test Case Title       : Short, descriptive name
3. Description          : What is being tested
4. Priority            : High/Medium/Low
5. Preconditions       : ต้องมีอะไรก่อนทดสอบ
6. Test Data          : Input values ที่ใช้
7. Test Steps         : ขั้นตอนการทดสอบทีละขั้น
8. Expected Results   : ผลลัพธ์ที่คาดหวัง
9. Actual Results     : ผลลัพธ์จริง (ใส่ตอน execute)
10. Status            : Pass/Fail/Blocked/Not Run
11. Postconditions    : สถานะของระบบหลังทดสอบ
```

### 3.3 ตัวอย่าง Test Case ที่ดี

```
Test Case ID: TC-001
Title: Successful user registration with valid data

Description:
Verify that a new user can register successfully with valid username, 
email, and password.

Priority: High

Preconditions:
- User is on the registration page
- Username "testuser123" does not exist in the database

Test Data:
- Username: testuser123
- Email: test@example.com
- Password: Test@1234

Test Steps:
1. Navigate to http://localhost:3000/register
2. Enter "testuser123" in the Username field
3. Enter "test@example.com" in the Email field
4. Enter "Test@1234" in the Password field
5. Click the "Register" button

Expected Results:
1. Registration form is displayed
2. All fields accept input correctly
3. "Register" button is clickable
4. After clicking Register:
   - Success message "Registration successful!" is displayed
   - User is redirected to the Login page within 2 seconds
   - New user record is created in the database

Actual Results: [To be filled during execution]

Status: Not Run

Postconditions:
- User "testuser123" exists in the database
- User can login with the registered credentials
```

### 3.4 Test Case Design Principles

#### **1. Clear and Concise**
- ใช้ภาษาที่ชัดเจน ไม่คลุมเครือ
- คนอื่นต้องเข้าใจและ execute ได้

#### **2. Independent**
- Test case ต้องทำงานได้อิสระ
- ไม่ depend on การ execute ของ test อื่น

#### **3. Repeatable**
- Run ซ้ำได้ ผลลัพธ์เหมือนเดิม
- มี data cleanup หรือ setup ที่ชัดเจน

#### **4. Traceable**
- Link กลับไปยัง requirement ได้
- มี Test Case ID ที่ชัดเจน

#### **5. Complete**
- Cover ทั้ง positive, negative และ edge cases
- มี expected results ครบถ้วน

### 3.5 Common Test Case Design Mistakes ❌

| Mistake | Example | Better Approach |
|---------|---------|-----------------|
| Vague steps | "Enter data" | "Enter 'testuser123' in Username field" |
| Missing expected results | "Click submit" | "Click submit → Success message displayed" |
| Too many scenarios in one TC | Testing login with 10 different inputs | Split into multiple test cases |
| No preconditions | Start testing | "User must be logged out before testing" |
| Hard-coded production data | "Login as admin@company.com" | "Login as {test_user_email}" |

---

## Part 4: Positive vs Negative Test Cases (20 นาที)

### 4.1 Positive Test Cases ✅

**วัตถุประสงค์:** ทดสอบว่าระบบทำงานถูกต้องตาม requirements เมื่อใช้ valid inputs

**ตัวอย่าง - User Registration:**

```
TC-001: Register with all valid data
- Username: john_doe (valid length, format)
- Email: john@example.com (valid format)
- Password: SecurePass123! (meets all requirements)
Expected: Registration successful ✅

TC-002: Register with minimum valid username length
- Username: john (4 characters - minimum allowed)
- Email: john@test.com
- Password: Pass1234
Expected: Registration successful ✅

TC-003: Register with maximum valid username length  
- Username: johnathan_doe_2024 (20 characters - maximum allowed)
- Email: john@test.com
- Password: Pass1234
Expected: Registration successful ✅
```

### 4.2 Negative Test Cases ❌

**วัตถุประสงค์:** ทดสอบว่าระบบ handle invalid inputs หรือ error conditions ได้ถูกต้อง

**ตัวอย่าง - User Registration:**

```
TC-004: Register with empty username
- Username: [empty]
- Email: john@example.com
- Password: Pass1234
Expected: Error message "Username is required" ❌

TC-005: Register with username too short (< 4 characters)
- Username: joe (3 characters)
- Email: john@example.com
- Password: Pass1234
Expected: Error message "Username must be at least 4 characters" ❌

TC-006: Register with username too long (> 20 characters)
- Username: johnathan_doe_smith_2024_user (28 characters)
- Email: john@example.com
- Password: Pass1234
Expected: Error message "Username must not exceed 20 characters" ❌

TC-007: Register with invalid email format
- Username: john_doe
- Email: invalid-email (no @ symbol)
- Password: Pass1234
Expected: Error message "Please enter a valid email address" ❌

TC-008: Register with duplicate username
- Username: existing_user (already exists in DB)
- Email: john@example.com
- Password: Pass1234
Expected: Error message "Username already exists" ❌

TC-009: Register with weak password (< 8 characters)
- Username: john_doe
- Email: john@example.com
- Password: Pass1 (5 characters)
Expected: Error message "Password must be at least 8 characters" ❌

TC-010: Register with special characters in username
- Username: john@doe! (contains special characters)
- Email: john@example.com
- Password: Pass1234
Expected: Error message "Username can only contain letters, numbers, and underscore" ❌
```

### 4.3 Coverage Strategy

**Golden Ratio:** 
- **60-70%** Positive test cases (happy paths)
- **30-40%** Negative test cases (error handling)

**Priority Strategy:**
1. **Critical Positive Cases** (High Priority) - Main workflows
2. **Critical Negative Cases** (High Priority) - Security, data integrity
3. **Edge Cases** (Medium Priority) - Boundary values
4. **Alternative Positive Flows** (Medium Priority)
5. **Rare Negative Cases** (Low Priority)

### 4.4 ตัวอย่างการจัดหมวดหมู่

**User Registration - Test Case Breakdown:**

| Type | Count | Examples |
|------|-------|----------|
| **Positive** | 8 | Valid registration, minimum/maximum lengths, special valid cases |
| **Negative - Validation** | 7 | Empty fields, invalid formats, length violations |
| **Negative - Business Logic** | 3 | Duplicate username, duplicate email, blacklisted email domain |
| **Edge Cases** | 2 | Unicode username, XSS attempt in username |
| **Total** | **20** | Comprehensive coverage |

---

## Part 5: Test Case Management (30 นาที)

### 5.1 ทำไมต้องมี Test Case Management?

❌ **Without Test Case Management:**
- Test cases กระจัดกระจายใน Word/Excel หลายไฟล์
- ไม่รู้ว่า test case ไหน execute แล้ว ไหนยัง
- ยากต่อการ collaborate กับทีม
- ไม่มี history ของการเปลี่ยนแปลง
- ไม่มี traceability กับ requirements

✅ **With Test Case Management:**
- Test cases อยู่ใน central repository
- Track execution status real-time
- Link กับ requirements และ defects
- Version control สำหรับ test cases
- Generate reports อัตโนมัติ

### 5.2 Test Case Management Tools

#### **1. TestLink (Open Source - Free)**

**Features:**
- Test plan management
- Requirements management
- Test case repository
- Test execution tracking
- Defect tracking integration (Jira, Bugzilla)
- Reports and metrics

**Pros:**
✅ Free และ open source
✅ Full-featured
✅ Web-based (accessible anywhere)
✅ Good for learning

**Cons:**
❌ UI ดูเก่า (dated interface)
❌ Setup ต้องใช้เวลา

#### **2. Zephyr for Jira (Commercial - Free tier available)**

**Features:**
- Native integration กับ Jira
- Modern UI
- Real-time collaboration
- Advanced reporting
- CI/CD integration

**Pros:**
✅ Modern interface
✅ Tight integration กับ Jira
✅ Better user experience

**Cons:**
❌ ต้องมี Jira account
❌ Free tier มีข้อจำกัด

#### **3. สำหรับหลักสูตรนี้: GitHub Issues + Google Sheets**

**Why?**
- ✅ Free 100%
- ✅ Students มี GitHub account อยู่แล้ว
- ✅ ใช้งานง่าย
- ✅ Integration กับ code repository
- ✅ Version control built-in

**Setup:**
```
1. GitHub Issues → Test case repository + defect tracking
2. Google Sheets → RTM + Test execution tracking
3. GitHub Projects → Test planning และ organization
```

### 5.3 Test Case Repository Structure

**Recommended Folder Structure:**

```
Test Cases/
├── 01_User_Management/
│   ├── Registration/
│   │   ├── TC-001_Valid_Registration.md
│   │   ├── TC-002_Invalid_Email.md
│   │   └── TC-003_Duplicate_Username.md
│   ├── Login/
│   │   ├── TC-010_Successful_Login.md
│   │   ├── TC-011_Invalid_Credentials.md
│   │   └── TC-012_Locked_Account.md
│   └── Profile/
│       └── ...
├── 02_Book_Management/
│   ├── Search/
│   ├── Borrow/
│   └── Return/
├── 03_Admin_Functions/
│   └── ...
└── RTM.xlsx
```

### 5.4 Test Execution Tracking

**Test Execution Sheet Format:**

| Test Cycle | Test Case ID | Tester | Execution Date | Status | Defect ID | Notes |
|------------|--------------|---------|----------------|--------|-----------|-------|
| Sprint 1 | TC-001 | John | 2024-01-15 | Pass | - | - |
| Sprint 1 | TC-002 | John | 2024-01-15 | Fail | BUG-042 | Email validation broken |
| Sprint 1 | TC-003 | Jane | 2024-01-16 | Pass | - | - |
| Sprint 2 | TC-002 | John | 2024-01-22 | Pass | - | Fixed in v1.1 |

**Execution Metrics Dashboard:**

```
Total Test Cases: 20
Executed: 18 (90%)
Passed: 15 (83%)
Failed: 3 (17%)
Blocked: 0
Not Run: 2 (10%)

Pass Rate: 83%
Defects Found: 5
```

---

## Part 6: Test Data Management (30 นาที)

### 6.1 Test Data คือ อะไร?

**Test Data** = ข้อมูลที่ใช้เป็น input และ expected output ในการทดสอบ

**ความท้าทาย:**
- ❌ ใช้ production data โดยตรง (security risk)
- ❌ Manual data creation (เสียเวลา, error-prone)
- ❌ Hard-coded data (maintenance nightmare)
- ❌ Insufficient variety (missed bugs)

### 6.2 Types of Test Data

#### **1. Static Data (Fixtures)**
ข้อมูลคงที่ที่เตรียมไว้ล่วงหน้า

```javascript
// fixtures/users.json
{
  "validUsers": [
    {
      "username": "john_doe",
      "email": "john@test.com",
      "password": "SecurePass123!"
    },
    {
      "username": "jane_smith",
      "email": "jane@test.com",
      "password": "AnotherPass456!"
    }
  ],
  "invalidEmails": [
    "invalid-email",
    "missing@domain",
    "@nodomain.com",
    "spaces in@email.com"
  ]
}
```

**Pros:**
✅ Predictable และ repeatable  
✅ เหมาะกับ regression testing  

**Cons:**
❌ ไม่ test ความหลากหลาย  
❌ ต้อง maintain manually  

#### **2. Dynamic Data (Generated)**
ข้อมูลที่ generate ทุกครั้งที่ run test

```javascript
import { faker } from '@faker-js/faker';

function generateTestUser() {
  return {
    username: faker.internet.userName(),
    email: faker.internet.email(),
    password: faker.internet.password({ length: 12 }),
    firstName: faker.person.firstName(),
    lastName: faker.person.lastName(),
    phone: faker.phone.number(),
    address: faker.location.streetAddress(),
    city: faker.location.city(),
    zipCode: faker.location.zipCode()
  };
}

// Generate 100 unique users
const testUsers = Array.from({ length: 100 }, generateTestUser);
```

**Pros:**
✅ ความหลากหลายสูง  
✅ ไม่ต้อง maintain  
✅ Test edge cases ที่ไม่คาดคิด  

**Cons:**
❌ Non-deterministic (random)  
❌ Debug ยากเมื่อเจอ bug  

### 6.3 @faker-js/faker Overview

**Installation:**
```bash
npm install --save-dev @faker-js/faker
```

**Common Faker Methods:**

```javascript
import { faker } from '@faker-js/faker';

// Personal Information
faker.person.firstName()          // "John"
faker.person.lastName()           // "Doe"
faker.person.fullName()           // "John Doe"
faker.person.sex()                // "male"
faker.person.jobTitle()           // "Software Engineer"

// Internet
faker.internet.email()            // "john.doe@example.com"
faker.internet.userName()         // "john_doe_123"
faker.internet.password()         // "aZ9!mK7pQ2"
faker.internet.url()              // "https://example.com"
faker.internet.ipv4()             // "192.168.1.1"

// Phone & Address
faker.phone.number()              // "+66-2-123-4567"
faker.location.streetAddress()    // "123 Main St"
faker.location.city()             // "Bangkok"
faker.location.country()          // "Thailand"
faker.location.zipCode()          // "10110"

// Date & Time
faker.date.past()                 // Past date
faker.date.future()               // Future date
faker.date.between({ from: '2024-01-01', to: '2024-12-31' })

// Commerce
faker.commerce.productName()      // "Intelligent Concrete Chair"
faker.commerce.price()            // "99.99"
faker.commerce.isbn()             // "978-0-123456-78-9"

// Lorem Ipsum
faker.lorem.sentence()            // Random sentence
faker.lorem.paragraph()           // Random paragraph
faker.lorem.words(5)              // 5 random words

// Numbers & Random
faker.number.int({ min: 1, max: 100 })      // Random int
faker.number.float({ min: 0, max: 1, precision: 0.01 }) // Random float
faker.helpers.arrayElement(['A', 'B', 'C']) // Random array element
```

### 6.4 Test Data Strategies

#### **Strategy 1: Hybrid Approach** (แนะนำ)

```javascript
// testData.js
import { faker } from '@faker-js/faker';

export class TestDataGenerator {
  
  // Static data สำหรับ smoke tests และ critical paths
  static VALID_USERS = [
    {
      username: 'testuser1',
      email: 'test1@example.com',
      password: 'Test@1234'
    },
    {
      username: 'testuser2',
      email: 'test2@example.com',
      password: 'Test@5678'
    }
  ];

  // Dynamic data สำหรับ data-driven tests
  static generateUser(overrides = {}) {
    return {
      username: faker.internet.userName(),
      email: faker.internet.email(),
      password: faker.internet.password({ length: 10 }),
      firstName: faker.person.firstName(),
      lastName: faker.person.lastName(),
      ...overrides  // Allow overriding specific fields
    };
  }

  // Generate specific invalid data
  static generateInvalidEmail() {
    const invalidFormats = [
      'notanemail',
      'missing@domain',
      '@nodomain.com',
      'user@',
      'user name@domain.com'
    ];
    return faker.helpers.arrayElement(invalidFormats);
  }

  // Boundary values
  static generateUsernameBoundary() {
    return {
      tooShort: faker.string.alpha(3),        // 3 chars (min is 4)
      minValid: faker.string.alpha(4),        // 4 chars (exactly min)
      maxValid: faker.string.alpha(20),       // 20 chars (exactly max)
      tooLong: faker.string.alpha(21)         // 21 chars (max is 20)
    };
  }
}
```

**Usage in Tests:**

```javascript
// Using static data (predictable)
test('Login with known valid user', () => {
  const user = TestDataGenerator.VALID_USERS[0];
  // ... test with static data
});

// Using dynamic data (variety)
test('Registration with random valid data', () => {
  const user = TestDataGenerator.generateUser();
  // ... test with generated data
});

// Using boundary data
test('Username length validation', () => {
  const usernames = TestDataGenerator.generateUsernameBoundary();
  // Test with tooShort, minValid, maxValid, tooLong
});

// Override specific fields
test('Registration with specific email domain', () => {
  const user = TestDataGenerator.generateUser({
    email: 'test@company.com',  // Override email
    username: 'john_doe'        // Override username
  });
  // ... test
});
```

### 6.5 Test Data Cleanup Strategy

**Problem:** Test data สะสมในระบบ → Database bloat, ผลทดสอบผิดพลาด

**Solutions:**

#### **1. Database Reset (ระหว่าง test runs)**

```javascript
// setup.js
beforeEach(async () => {
  // Reset database to clean state
  await database.query('TRUNCATE TABLE users RESTART IDENTITY CASCADE');
  await database.query('TRUNCATE TABLE books RESTART IDENTITY CASCADE');
  
  // Seed essential data
  await seedEssentialData();
});

afterEach(async () => {
  // Cleanup test data
  await cleanupTestData();
});
```

#### **2. Naming Convention (Track test data)**

```javascript
// Prefix test data with identifier
const testUser = {
  username: `TEST_${faker.internet.userName()}`,
  email: `test_${faker.internet.email()}`
};

// Easy to identify and cleanup
await database.query("DELETE FROM users WHERE username LIKE 'TEST_%'");
```

#### **3. Separate Test Database**

```javascript
// config/database.js
const config = {
  development: {
    database: 'library_dev'
  },
  test: {
    database: 'library_test'  // Separate DB for tests
  },
  production: {
    database: 'library_prod'
  }
};

// Tests always run against test database
const db = process.env.NODE_ENV === 'test' ? 
  config.test.database : 
  config.development.database;
```

#### **4. Transaction Rollback**

```javascript
describe('User Registration', () => {
  let transaction;
  
  beforeEach(async () => {
    transaction = await database.transaction();
  });
  
  afterEach(async () => {
    await transaction.rollback(); // Rollback all changes
  });
  
  test('Register user', async () => {
    // All DB changes within transaction
    const user = await createUser(testData, { transaction });
    // ... assertions
  }); // Auto-rollback after test
});
```

### 6.6 Best Practices for Test Data Management

✅ **DO:**
- Use faker for generating realistic data
- Separate test data logic into reusable modules
- Document test data requirements in test cases
- Use fixtures for critical, repeatable scenarios
- Clean up test data after execution
- Use separate test database
- Version control your test data fixtures

❌ **DON'T:**
- Use production data in tests (privacy, security)
- Hard-code test data in test scripts
- Reuse same test data across multiple tests (coupling)
- Leave test data in database after tests
- Use sequential IDs (causes conflicts)
- Ignore data cleanup strategies

---

## 🎯 Summary: Key Takeaways

### Requirements Analysis
- Good requirements are SMART (Specific, Measurable, Achievable, Relevant, Testable)
- Always ask clarifying questions before writing test cases
- Understand both functional and non-functional requirements

### RTM
- RTM ensures 100% requirements coverage
- Maintains traceability from requirements → tests → defects
- Living document that must be updated regularly

### Test Case Design
- Good test cases are: Clear, Independent, Repeatable, Traceable, Complete
- Each test case must have: ID, Description, Steps, Expected Results
- Write test cases ให้คนอื่นเข้าใจและ execute ได้

### Positive vs Negative Testing
- Positive: ทดสอบ valid scenarios (60-70%)
- Negative: ทดสอบ error handling (30-40%)
- Cover ทั้ง happy paths, edge cases, และ error conditions

### Test Case Management
- Use central repository (GitHub Issues / TestLink)
- Track execution status และ defects
- Generate reports และ metrics

### Test Data Management
- Use @faker-js/faker สำหรับ dynamic data generation
- Hybrid approach: Static data + Dynamic data
- Always cleanup test data
- Never use production data in tests

---

## 📚 Additional Resources

**Tools:**
- faker-js Documentation: https://fakerjs.dev/
- TestLink: https://testlink.org/
- GitHub Projects: https://docs.github.com/en/issues/planning-and-tracking-with-projects

**Reading:**
- "Software Testing" by Ron Patton (Chapter 4-5)
- IEEE 829 Test Documentation Standard
- ISTQB Foundation Syllabus (Chapter 4)

---

## 🔜 Next Week Preview

**สัปดาห์ที่ 5: Black Box Testing Techniques**
- Equivalence Partitioning (EP)
- Boundary Value Analysis (BVA)
- Decision Table Testing
- State Transition Testing

**Preparation:**
- Review ความรู้เกี่ยว partition และ boundary values
- ทำความเข้าใจ business rules ของ Book Borrowing ใน Library System