โครงสร้างของ Test Case ที่ดี
Test case ที่ดีไม่ใช่แค่เขียนขั้นตอน — มันต้องชัดเจนพอที่คนอื่นอ่านแล้วเทสต์ได้เหมือนกันทุกครั้ง โดยไม่ต้องถามผู้เขียน
จบบทนี้แล้วคุณจะ...
- อธิบายองค์ประกอบทั้งหมดของ test case ที่ดีได้
- แยกแยะ test case ที่ดีกับไม่ดีได้
- เข้าใจหลักการ traceability ระหว่าง test case กับ requirement
- เข้าใจความสำคัญของ priority และ severity ใน test case
มากกว่าแค่ "ขั้นตอนการเทสต์"
Test case คือ "เอกสาร" ที่บอกผู้ทดสอบว่าต้องทำอะไร ทีละขั้น และผลลัพธ์ที่คาดหวังคืออะไร แต่ test case ที่ดีมีมากกว่าแค่ขั้นตอน — มันคือ "สัญญา" ระหว่าง QA กับทีมว่า "เราเทสต์อะไรบ้าง และถือว่าผ่านเมื่อไร"
ลองจินตนาการว่าคุณเขียน test case ไว้ แล้ววันหนึ่งคุณลาป่วย เพื่อนร่วมทีมที่ไม่เคยเห็นระบบนี้มาก่อนต้องมาเทสต์แทน ถ้าเขาอ่าน test case ของคุณแล้วเทสต์ได้เหมือนกับที่คุณเทสต์ — นั่นคือ test case ที่ดี ถ้าเขาต้องโทรมาถามคุณ — นั่นคือ test case ที่ยังไม่ดีพอ
9 ส่วนที่ test case ที่ดีต้องมี
| องค์ประกอบ | คำอธิบาย | ตัวอย่าง |
|---|---|---|
| Test Case ID | รหัสเฉพาะที่ไม่ซ้ำ | TC-LOGIN-001 |
| Title | ชื่อสั้นๆ บอกว่าเทสต์อะไร | "Login ด้วย email และ password ที่ถูกต้อง" |
| Preconditions | เงื่อนไขที่ต้องเป็นจริงก่อนเริ่ม | "มี account ที่ active อยู่ในระบบ" |
| Test Steps | ขั้นตอนทีละ step | 1. เปิดหน้า login 2. กรอก email... |
| Test Data | ข้อมูลที่ใช้ในการเทสต์ | email: [email protected], password: P@ss1234 |
| Expected Result | ผลลัพธ์ที่คาดว่าจะเกิดขึ้น | "ระบบพาไปหน้า dashboard แสดงชื่อผู้ใช้" |
| Actual Result | ผลลัพธ์ที่เกิดขึ้นจริง (กรอกตอนเทสต์) | "ระบบพาไปหน้า dashboard — PASS" |
| Priority/Severity | ความสำคัญและความรุนแรง | Priority: High, Severity: Critical |
| Traceability | อ้างอิง requirement ที่เกี่ยวข้อง | REQ-AUTH-001 |
สองคำที่ต่างกันแต่คนมักสับสน
Severity คือ "ระดับความรุนแรง" ของปัญหาถ้า test case fail — กระทบระบบแค่ไหน:
- Critical: ระบบล่มทั้งหมด, data loss, security breach
- High: ฟีเจอร์หลักใช้ไม่ได้ แต่มี workaround
- Medium: ฟีเจอร์รองมีปัญหา
- Low: ปัญหาเล็กน้อย เช่น typo, UI alignment
Priority คือ "ลำดับความเร่งด่วน" ในการแก้ไข — ธุรกิจต้องการให้แก้เร็วแค่ไหน:
- P1: ต้องแก้ทันที (blocking release)
- P2: ต้องแก้ก่อน release
- P3: แก้ได้ใน sprint ถัดไป
- P4: แก้เมื่อมีเวลา
ตัวอย่างที่ทำให้เห็นภาพ:
| สถานการณ์ | Severity | Priority |
|---|---|---|
| ปุ่ม "ชำระเงิน" กดไม่ได้ | Critical | P1 |
| Logo ของบริษัทบนหน้า About Us ผิด | Low | P1 (ถ้า CEO สั่ง) |
| ฟีเจอร์ export PDF ใช้ไม่ได้ | High | P3 (ถ้าแทบไม่มีคนใช้) |
| สีปุ่มผิดไป 1 shade | Low | P4 |
สังเกตว่า severity กับ priority ไม่จำเป็นต้องตรงกัน — Logo ผิดอาจ severity ต่ำ (ระบบยังทำงานได้) แต่ priority สูง (ผู้บริหารต้องการให้แก้ทันที)
ทุก Test Case ต้องอ้างอิงกลับไปที่ Requirement
Traceability คือการเชื่อมโยงระหว่าง requirement → test case → defect ซึ่งมีประโยชน์มหาศาล:
- ครอบคลุม: เห็นว่า requirement ไหนยังไม่มี test case
- ติดตาม: เมื่อ requirement เปลี่ยน รู้ว่าต้อง update test case ไหนบ้าง
- รายงาน: บอกได้ว่า requirement ไหนเทสต์ผ่านแล้ว ไหนยังไม่ผ่าน
- ตรวจสอบ: เห็นว่า test case ไหน "ไม่มี requirement รองรับ" (อาจเป็น test case ที่ไม่จำเป็น)
ตัวอย่าง Traceability Matrix:
| Requirement | Test Cases | Status |
|---|---|---|
| REQ-001: Login | TC-001, TC-002, TC-003 | 2/3 Pass |
| REQ-002: Registration | TC-004, TC-005 | 1/2 Pass |
| REQ-003: Password Reset | (ยังไม่มี test case) | Not Tested |
เปรียบเทียบให้เห็นชัด
Test Case ที่ไม่ดี:
TC-001: ทดสอบ login Steps: login เข้าระบบ Expected: login ได้
ปัญหา: ไม่มี precondition, ไม่มี test data, ขั้นตอนไม่ละเอียด, expected result คลุมเครือ — คนอื่นอ่านแล้วเทสต์ไม่ได้
Test Case ที่ดี:
TC-LOGIN-001: Login ด้วย email และ password ที่ถูกต้อง Preconditions: มี account email: [email protected], password: Test@1234 ที่ active อยู่ในระบบ Steps:
- เปิด browser ไปที่ https://app.example.com/login
- กรอก email: [email protected]
- กรอก password: Test@1234
- กดปุ่ม "เข้าสู่ระบบ" Expected Result: ระบบแสดงหน้า dashboard พร้อมข้อความ "สวัสดี [email protected]" ที่มุมบนขวา Priority: High | Severity: Critical Traceability: REQ-AUTH-001
แบบฝึก: วิเคราะห์ Test Case ที่ดีและไม่ดี
Test case ต่อไปนี้มีปัญหาอะไรบ้าง?
TC-099: ทดสอบการสมัครสมาชิก Steps: กรอกข้อมูลแล้วกดสมัคร Expected: สมัครได้
ดูคำตอบแนะนำ
ปัญหา:
- ไม่มี Preconditions: ไม่บอกว่าต้องอยู่หน้าไหน ต้องมี account อยู่แล้วหรือไม่
- ไม่มี Test Data: "กรอกข้อมูล" — ข้อมูลอะไร? ค่าอะไรบ้าง?
- Steps ไม่ละเอียด: "กรอกข้อมูลแล้วกดสมัคร" — กรอกกี่ช่อง? กดปุ่มอะไร?
- Expected Result คลุมเครือ: "สมัครได้" — แสดงอะไร? ไปหน้าไหน? ส่ง email ไหม?
- ไม่มี Priority/Severity
- ไม่มี Traceability
จงเขียน test case ที่ดีสำหรับ "การเพิ่มสินค้าลงตะกร้า" โดยมีครบทุกองค์ประกอบ
ดูคำตอบแนะนำ
TC-CART-001: เพิ่มสินค้าลงตะกร้าสำเร็จ Preconditions: ผู้ใช้ login เข้าระบบแล้ว, สินค้า "เสื้อยืดสีดำ" (SKU: BLK-001) มี stock เหลืออยู่ Steps:
- เปิดหน้า catalog ไปที่หมวด "เสื้อยืด"
- คลิกที่สินค้า "เสื้อยืดสีดำ" (SKU: BLK-001)
- เลือก size: M
- กรอกจำนวน: 1
- กดปุ่ม "เพิ่มลงตะกร้า" Expected Result: แสดง notification "เพิ่มสินค้าลงตะกร้าแล้ว", icon ตะกร้ามุมบนขวาแสดงจำนวน 1, คลิกที่ตะกร้าจะเห็นสินค้า "เสื้อยืดสีดำ size M x1" Priority: High | Severity: Critical Traceability: REQ-CART-001
ทำไม traceability ถึงสำคัญ? ยกตัวอย่างสถานการณ์ที่ไม่มี traceability แล้วเกิดปัญหา
ดูคำตอบแนะนำ
สถานการณ์: PM แจ้งว่า requirement การคำนวณส่วนลดเปลี่ยน — จากเดิม "ลด 10% เมื่อซื้อครบ 1,000 บาท" เป็น "ลด 15% เมื่อซื้อครบ 500 บาท"
ถ้าไม่มี traceability: QA ต้องค้นหาเองว่า test case ไหนบ้างที่เกี่ยวกับส่วนลด อาจพลาดบาง test case ที่ใช้ค่า 10% หรือ 1,000 บาท ทำให้เทสต์ไม่ครบ บั๊กหลุดไป production
ถ้ามี traceability: เปิด traceability matrix ดู REQ-DISC-001 จะเห็นทันทีว่ามี TC-DISC-001 ถึง TC-DISC-005 ที่ต้อง update แก้ test data ให้ตรงกับ requirement ใหม่ ไม่มีอะไรตกหล่น
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- Test case ที่ดีต้องมี 9 องค์ประกอบ: ID, Title, Preconditions, Steps, Test Data, Expected Result, Actual Result, Priority/Severity, Traceability
- ทดสอบ "ความดี" ของ test case ด้วยการถามว่า "คนอื่นอ่านแล้วเทสต์ได้ไหม?"
- Severity คือความรุนแรงทางเทคนิค, Priority คือความเร่งด่วนทางธุรกิจ — ทั้งสองไม่จำเป็นต้องตรงกัน
- Traceability เชื่อม requirement กับ test case — ช่วยให้ไม่มีอะไรตกหล่นเมื่อ requirement เปลี่ยน