ฝึกเขียน Test Case จริง

กฎ 3 ข้อของ Steps ที่ดี

กฎข้อ 1: หนึ่ง Step = หนึ่ง Action

• ผิด: "เปิดหน้า login แล้วกรอก email และ password แล้วกด submit"
• ถูก:
  1. เปิดหน้า login
  2. กรอก email: [email protected]
  3. กรอก password: Test@1234
  4. กดปุ่ม "เข้าสู่ระบบ"

กฎข้อ 2: ระบุค่าที่แน่นอน ไม่ใช่คำคลุมเครือ

• ผิด: "กรอก email ที่ถูกต้อง"
• ถูก: "กรอก email: [email protected]"

กฎข้อ 3: ระบุ element ที่ต้องโต้ตอบให้ชัด

• ผิด: "กดปุ่ม"
• ถูก: "กดปุ่ม 'เข้าสู่ระบบ' ที่อยู่ด้านล่างฟอร์ม"

5 ข้อผิดพลาดที่มือใหม่ทำเป็นประจำ

ข้อผิดพลาดที่ 1: Expected Result ที่คลุมเครือ

• ผิด: "ระบบทำงานถูกต้อง"
• ถูก: "ระบบแสดงหน้า dashboard พร้อม notification 'ยินดีต้อนรับ สมชาย' ที่มุมบนขวา"

ข้อผิดพลาดที่ 2: ลืม Preconditions

• ผิด: เริ่มที่ "กดปุ่มแก้ไข profile" โดยไม่บอกว่าต้อง login ก่อน
• ถูก: Preconditions: "ผู้ใช้ login ด้วย account: [email protected], อยู่ที่หน้า Profile Settings"

ข้อผิดพลาดที่ 3: สมมติว่าผู้อ่านรู้ระบบ

• ผิด: "ไปหน้า settings แล้วเปิด toggle นั้น"
• ถูก: "คลิก icon รูปเฟือง ที่ sidebar ซ้าย → เลือก 'Notification Settings' → เปิด toggle 'Email Notifications'"

ข้อผิดพลาดที่ 4: Test Data ไม่ realistic

• ผิด: ใช้ email "[email protected]" ชื่อ "test test"
• ถูก: ใช้ email "[email protected]" ชื่อ "สมชาย ใจดี" — ข้อมูลจริงช่วยเจอบั๊กเรื่อง encoding, ความยาว, ภาษา

ข้อผิดพลาดที่ 5: รวม positive และ negative ไว้ใน test case เดียว

• ผิด: "กรอกข้อมูลถูกต้อง → สำเร็จ. กรอกผิด → error." (ใน TC เดียว)
• ถูก: แยกเป็น TC-001 (positive) และ TC-002 (negative) — แต่ละ test case ต้องมีผลลัพธ์เดียวที่ชัดเจน

เขียนครั้งเดียว ใช้ได้หลายรอบ

Test case ที่ดีควรออกแบบให้ "นำไปใช้ซ้ำได้" ไม่ว่าจะรันในสภาพแวดล้อมไหน:

หลักการ 1: แยก Test Data ออกจาก Test Steps แทนที่จะ hardcode ค่าในขั้นตอน ให้อ้างอิง test data แยกต่างหาก:

Steps:

1. เปิดหน้า login
2. กรอก email: [TEST_EMAIL]
3. กรอก password: [TEST_PASSWORD]
4. กดปุ่ม "เข้าสู่ระบบ"

Test Data Set 1: TEST_EMAIL = [email protected], TEST_PASSWORD = Admin@1234 Test Data Set 2: TEST_EMAIL = [email protected], TEST_PASSWORD = User@5678

หลักการ 2: ใช้ Shared Preconditions ถ้าหลาย test case มี precondition เหมือนกัน (เช่น "login แล้ว") ให้สร้าง "common setup" ที่อ้างอิงได้:

Precondition: [SETUP-LOGIN] (อ้างอิง setup procedure สำหรับ login)

หลักการ 3: ทำให้ test case เป็นอิสระจากกัน

• ผิด: "TC-002 ต้องรัน TC-001 ก่อน"
• ถูก: แต่ละ TC มี precondition ของตัวเอง สามารถรันในลำดับไหนก็ได้

ข้อมูลทดสอบที่ดีเจอบั๊กได้มากกว่า

Valid Data: ข้อมูลที่ถูกต้องตามเงื่อนไข

• ชื่อ: "สมชาย ใจดี" (ภาษาไทย, มีเว้นวรรค)
• email: "[email protected]" (มี subdomain)
• เบอร์โทร: "0891234567" (10 หลัก, เริ่มด้วย 0)

Invalid Data: ข้อมูลที่ผิดเงื่อนไข

• email: "user@" (ไม่มี domain)
• เบอร์โทร: "12345" (สั้นเกินไป)
• จำนวนสินค้า: "-1" (ค่าติดลบ)

Boundary Data: ข้อมูลที่อยู่ตรงขอบ

• password ยาว 8 ตัว (ขั้นต่ำ), 7 ตัว (ต่ำกว่าขั้นต่ำ 1)
• จำนวนสินค้า: 0, 1, 99, 100 (ถ้าสูงสุด 99)

Special Data: ข้อมูลพิเศษที่มักทำให้ระบบมีปัญหา

• ชื่อที่มี apostrophe: "O'Brien"
• text ที่มี HTML: ""
• ค่าที่ยาวมาก: string 10,000 ตัวอักษร
• emoji: "สมชาย 🎉"

จาก Requirement สู่ Test Case

Requirement: "ผู้ใช้สามารถปรับจำนวนสินค้าในตะกร้าได้ (1-99 ชิ้น) ราคารวมต้องคำนวณใหม่ทันที"

TC-CART-010: ปรับจำนวนสินค้าจาก 1 เป็น 3

• Preconditions: ผู้ใช้ login แล้ว, มีสินค้า "เสื้อยืดสีดำ" ราคา 350 บาท อยู่ในตะกร้า จำนวน 1 ชิ้น
• Steps:
  1. เปิดหน้าตะกร้าสินค้า
  2. ที่สินค้า "เสื้อยืดสีดำ" เปลี่ยนจำนวนจาก 1 เป็น 3
  3. สังเกตราคารวมของสินค้ารายการนี้
  4. สังเกตราคารวมทั้งหมดของตะกร้า
• Expected Result: ราคารวมรายการ = 1,050 บาท (350 x 3), ราคารวมตะกร้า update ทันที
• Priority: High | Severity: High
• Traceability: REQ-CART-003