Section 01 · Module 07 · Lesson 02 · ~24–28 นาที

ลงมือเขียน Test Scenario และ Checklist จริง ๆ

หลักการครบแล้ว ถึงเวลาทำจริง บทนี้จะพาคุณเอา requirement ที่อ่านและแตก test conditions แล้ว มาสรุปเป็น test scenario และ checklist ที่อ่านง่าย ใช้ต่อได้ และ trace กลับไปยัง requirement หรือ risk ได้

เวลาเรียน: 24–28 นาที ต้องรู้มาก่อน: Module 05, Module 07 Lesson 01 รูปแบบ: ฝึกเขียนจาก requirement จริง

จบบทนี้แล้วคุณจะ...

เขียน test scenario ที่สั้น ชัด และสะท้อน user flow ได้ดีขึ้น
เขียน checklist ที่รันเร็วและไม่พลาดข้อสำคัญ
รู้ว่า scenario กับ checklist ต่างกันตรงไหน และไม่เอามาปนกัน
เชื่อม output ที่เขียนกลับไปหา requirement, criteria หรือ risk ได้
พร้อมต่อยอดไปสู่ final workshop และการทำงานจริงในโปรเจกต์

1 · ก่อนเขียน ต้องรู้ก่อนว่ากำลังจะเขียนอะไร

Scenario ไม่ใช่ case และ checklist ก็ไม่ใช่ scenario แบบย่อ

หลายคนเริ่มเขียนแล้วสับสน เพราะสามอย่างนี้ดูคล้ายกันแต่หน้าที่ไม่เหมือนกัน

สิ่งที่เขียน	ใช้เมื่อ	หน้าตาโดยย่อ
Test Scenario	อยากสรุปว่ามี flow อะไรต้องทดสอบ	"ผู้ใช้สมัครสมาชิกและยืนยันอีเมลสำเร็จ"
Test Case	อยากบอก step-by-step อย่างละเอียด	1. เปิดหน้า 2. กรอกค่า 3. กดปุ่ม 4. ตรวจ expected
Checklist	อยากมีรายการเช็กเร็ว ๆ	☐ Login ได้ ☐ Search ได้ ☐ Checkout ได้

ถ้าจะจำสั้น ๆ

Scenario = เราต้องทดสอบ flow อะไร
Case = เราจะ execute flow นั้นยังไง
Checklist = มีอะไรที่ต้องเช็กให้ครบ

บทนี้จะเน้น scenario กับ checklist เพราะสองอย่างนี้เป็น output ที่ใช้บ่อยมากในงานประจำวันของ QA

2 · วิธีเขียน Test Scenario ที่ดี

เขียนจากมุม user flow หรือ business outcome ไม่ใช่มุมปุ่มบนหน้าจอ

Scenario ที่ดีควรบอกว่า:

ใครกำลังทำอะไร
เพื่อให้เกิดผลลัพธ์อะไร
มีเงื่อนไขหรือสถานะสำคัญอะไรเกี่ยวข้อง

สูตรง่ายสำหรับเขียน Scenario

[ผู้ใช้/บทบาท] + [ทำอะไร] + [ภายใต้เงื่อนไขอะไร] + [ผลที่คาดหวัง]

ตัวอย่าง:

ลูกค้าสมัครสมาชิกด้วยอีเมลใหม่และได้รับลิงก์ยืนยัน
ลูกค้าใช้คูปองหมดอายุในหน้า checkout แล้วระบบปฏิเสธ
แอดมินอนุมัติคำขอ refund แล้วสถานะ order ถูกอัปเดต

ตัวอย่างที่ไม่ดี vs ดี

แบบที่ยังไม่ดี	ปัญหา	แบบที่ดีขึ้น
"กดปุ่ม Submit"	ไม่มีบริบท	"ผู้ใช้ส่งแบบฟอร์มสมัครสมาชิกสำเร็จ"
"ทดสอบ email invalid"	กว้างเกิน	"ผู้ใช้กรอก email ที่ไม่มี @ และเห็น validation error"
"checkout"	สั้นเกินจนไม่รู้จะพิสูจน์อะไร	"ผู้ใช้ checkout สำเร็จด้วยบัตรที่ถูกต้อง"

Scenario ที่ดีควรมีคุณสมบัติ 4 อย่าง

ชัดว่า flow ไหน
ไม่ผูกกับ UI รายละเอียดเกินไป
อ่านแล้วนึก expected behavior ออก
แยกคนละ flow ไม่ยัดหลายเรื่องในข้อเดียว

3 · วิธีเขียน Checklist ที่ใช้ได้จริง

เขียนเพื่อให้ "เช็กได้เร็ว" ไม่ใช่เขียนให้ดูครบทุกความคิด

Checklist เหมาะกับงานที่ต้องการ:

รันเร็ว
ใช้ซ้ำ
ช่วยกันรันได้หลายคน
ไม่ต้องลง step ละเอียด

Checklist ที่ดีควรเป็นแบบนี้

หลักการ	ตัวอย่าง
แต่ละข้อเช็กเรื่องเดียว	"Login ได้" ดีกว่า "Login แล้วไปหน้า dashboard และ export report ได้"
ใช้คำกริยาชัด	Check, Verify, Confirm, Open
เรียงตาม flow	Login → Home → Main feature → Logout
ยาวพอดี	ถ้ายาวเกิน 15–20 ข้อ ควรแยกชุด
มีบริบทเท่าที่จำเป็น	เช่น บอก role, browser, environment ถ้าสำคัญ

Checklist ไม่ควรเป็นแบบนี้

ยาวจนกลายเป็น test case แฝง
กว้างเกิน เช่น "ทุกอย่างทำงานได้"
หลายเงื่อนไขในข้อเดียว เช่น "สมัครได้ ส่งอีเมลได้ และ login ได้"

4 · Walkthrough: จาก Requirement ไปสู่ Scenario

ลองทำจากตัวอย่างจริงทีละขั้น

Requirement "ผู้ใช้สามารถกู้รหัสผ่านได้โดยกรอก email ที่ลงทะเบียนไว้ ระบบจะส่งลิงก์ reset password ผ่านอีเมล ลิงก์มีอายุ 1 ชั่วโมง"

ขั้นที่ 1: แยกสิ่งที่ต้องพิสูจน์

จาก requirement นี้ เราเห็นอย่างน้อย 5 เรื่อง:

ขอ reset ได้ด้วย email ที่มีในระบบ
email ที่ไม่มีในระบบต้องถูก handle อย่างเหมาะสม
ระบบส่งลิงก์ reset
ลิงก์ใช้งานได้ภายใน 1 ชั่วโมง
ลิงก์หมดอายุหลัง 1 ชั่วโมง

ขั้นที่ 2: เขียนเป็น Scenario

ผู้ใช้ขอ reset password สำเร็จด้วย email ที่ลงทะเบียนไว้
ผู้ใช้ขอ reset password ด้วย email ที่ไม่มีในระบบ
ผู้ใช้เปิดลิงก์ reset ภายใน 1 ชั่วโมงและเปลี่ยนรหัสผ่านสำเร็จ
ผู้ใช้เปิดลิงก์ reset หลังเกิน 1 ชั่วโมงแล้วถูกปฏิเสธ
ผู้ใช้กดขอลิงก์ reset ซ้ำหลายครั้งภายในช่วงเวลาสั้น
ผู้ใช้เปิดลิงก์เดิมซ้ำหลังเปลี่ยนรหัสผ่านสำเร็จแล้ว

สังเกตว่า Scenario ที่ดี

แยก flow ปกติและ flow ผิดออกจากกัน
ไม่ลง step แต่บอกชัดว่ากำลังพิสูจน์อะไร
สามารถ trace กลับ requirement ได้

5 · Walkthrough: จาก Scenario ไปสู่ Checklist

Checklist จะไม่เหมือน scenario แบบ copy มาวาง

สมมติเราต้องทำ smoke checklist สำหรับฟีเจอร์ reset password เดียวกัน

สิ่งที่เราอยากเช็กเร็ว ๆ หลัง deploy อาจเป็น:

☐ เปิดหน้า forgot password ได้
☐ ส่งคำขอ reset ด้วย account ทดสอบได้
☐ อีเมล reset ถูกส่งออก
☐ เปิดลิงก์ reset จากอีเมลได้
☐ ตั้งรหัสผ่านใหม่สำเร็จ
☐ login ด้วยรหัสใหม่ได้

ทำไม checklist นี้ต่างจาก scenario

เพราะ checklist ชุดนี้ออกแบบมาเพื่อ:

run เร็ว
เช็ก flow หลัก
ใช้ยืนยันว่า release ยังไม่พัง

มันไม่ได้พยายามครอบคลุมทุก alternate path และ edge case แบบชุด scenario เต็ม

6 · ตัวอย่างอีกแบบ: เขียนจาก Requirement ของ Newsletter

requirement หนึ่งใบ อาจได้ทั้ง scenario และ checklist คนละชุด

Requirement "ผู้ใช้สามารถสมัครรับ newsletter โดยกรอก email ระบบต้องยืนยันการสมัครผ่านอีเมลก่อนจึงจะ active"

ตัวอย่าง Test Scenarios

ผู้ใช้สมัคร newsletter สำเร็จด้วย email ใหม่ที่ valid
ผู้ใช้สมัครด้วย email ที่ format ผิดและถูกปฏิเสธ
ผู้ใช้สมัครด้วย email ที่เคย active อยู่แล้ว
ผู้ใช้คลิกลิงก์ยืนยันภายในเวลาที่กำหนดและ active สำเร็จ
ผู้ใช้คลิกลิงก์ยืนยันหลังหมดอายุ
ผู้ใช้คลิกลิงก์ยืนยันซ้ำสองครั้ง
ผู้ใช้ unsubscribe แล้วสมัครใหม่อีกครั้ง

ตัวอย่าง Smoke Checklist

☐ เปิดฟอร์มสมัคร newsletter ได้
☐ กรอก email valid และ submit ได้
☐ ระบบส่งอีเมลยืนยัน
☐ เปิดลิงก์ยืนยันแล้ว active สำเร็จ
☐ หลัง active แล้วสถานะในระบบเปลี่ยนถูกต้อง

บทเรียนจากตัวอย่างนี้

Scenario ช่วยให้เห็น coverage ของ flow ทั้งหมด ส่วน checklist ช่วยให้ทีม run ชุดเช็กสั้น ๆ ในเวลาจำกัด

7 · วิธีเชื่อม Output กลับไปหา Requirement

เขียนดีอย่างเดียวไม่พอ ต้อง trace ได้ด้วย

ถ้าเขียน scenario หรือ checklist แล้วไม่รู้ว่ามาจาก requirement ข้อไหน เวลามีการเปลี่ยน requirement คุณจะอัปเดตยากมาก

วิธีง่าย ๆ ที่ใช้ได้ทันที:

ใส่ reference เช่น AC-1, AC-2, RISK-PAY-01
แยกหัวข้อหรือ section ให้สัมพันธ์กับ flow
ถ้าใช้ spreadsheet ให้มีคอลัมน์ Source หรือ Reference

ตัวอย่าง

ID	Output	Reference
SCN-01	ผู้ใช้สมัคร newsletter สำเร็จ	AC-1
SCN-04	ผู้ใช้คลิกลิงก์ยืนยันภายในเวลา	AC-2
CHK-03	อีเมลยืนยันถูกส่งออก	AC-2

traceability ไม่ได้ทำเพื่อความสวย แต่มันช่วยให้:

อัปเดตเอกสารได้เร็วเมื่อ requirement เปลี่ยน
อธิบาย impact ได้เมื่อมี defect
รู้ว่ามี coverage gap ตรงไหน

8 · ข้อผิดพลาดที่พบบ่อยเวลาเขียน Scenario และ Checklist

Scenario ผูกกับ UI มากเกินไป

เช่น "กดปุ่มสีเขียวมุมขวา" ถ้า UI เปลี่ยน scenario จะเสียทันที

Scenario กว้างเกินไป

เช่น "ทดสอบการสมัครสมาชิก" ซึ่งรวมทุก flow ไว้ในข้อเดียวจนใช้ต่อยาก

Checklist ยาวจนอ่านไม่ไหว

ถ้าทีมต้องใช้ 20 นาทีเพื่อ run smoke checklist มันอาจไม่ใช่ smoke แล้ว

Checklist หลายเรื่องในข้อเดียว

เช่น "สมัครได้ ส่งอีเมลได้ และเข้าใช้งานได้" ถ้าพังจะไม่รู้ว่าพังตรงไหน

ไม่มี reference

สุดท้ายจะกลับไปตอบไม่ได้ว่ารายการนี้ปกป้อง requirement ข้อไหน

Practice

แบบฝึก: เขียน scenario และ checklist ด้วยตัวเอง

จาก requirement "ผู้ใช้สามารถสมัครรับ newsletter โดยกรอก email ระบบต้องยืนยันการสมัครผ่านอีเมลก่อนจึงจะ active" ลองเขียน test scenario อย่างน้อย 5 ข้อ
ดูคำตอบแนะนำ
1. สมัครสำเร็จด้วย email ใหม่ที่ format ถูก
2. สมัครด้วย email format ผิด
3. สมัครด้วย email ที่ active อยู่แล้ว
4. คลิกลิงก์ยืนยันภายในเวลาที่กำหนดและ active สำเร็จ
5. คลิกลิงก์หลังหมดอายุ
6. คลิกลิงก์ยืนยันสองครั้ง
7. unsubscribe แล้วสมัครใหม่อีกครั้ง
เขียน smoke checklist สำหรับ "ระบบ internal dashboard ของบริษัท" ไม่เกิน 10 ข้อ
ดูคำตอบแนะนำ
- Login ด้วย SSO สำเร็จ
- หน้า dashboard โหลดสำเร็จ
- widget หลักแสดงข้อมูล
- filter วันที่ใช้งานได้
- export report ได้
- เปิดหน้ารายละเอียดจาก dashboard ได้
- กลับมาหน้าหลักได้
- logout ได้
Requirement: "ลูกค้าสามารถใช้คูปองส่วนลดตอน checkout ได้ถ้ายอดซื้อครบ 500 บาท" เขียนได้ไหมว่าเป็น scenario แบบไหนบ้าง และ checklist ชุดสั้น ๆ ควรเช็กอะไร

ดูคำตอบแนะนำ

ตัวอย่าง Scenario: ลูกค้าใช้คูปองสำเร็จเมื่อยอดครบ 500 บาท, ลูกค้าใช้คูปองไม่ได้เมื่อยอดต่ำกว่า 500 บาท, ลูกค้าใส่คูปองหมดอายุแล้วระบบปฏิเสธ, ลูกค้าใส่คูปองแล้วลบสินค้าออกจนยอดต่ำกว่าเกณฑ์

ตัวอย่าง Checklist: ใส่คูปองถูกเมื่อยอดครบ 500 แล้วหักส่วนลดได้, ยอดต่ำกว่า 500 แล้วระบบไม่ให้ใช้คูปอง, หน้า checkout แสดงยอดใหม่ถูกต้อง, order summary สะท้อนส่วนลดถูกต้อง

สิ่งที่ต้องเอาติดตัวไปจากบทนี้

Scenario เขียนจาก flow หรือ business outcome, Checklist เขียนเพื่อเช็กเร็ว
อย่าเขียน scenario แบบผูก UI และอย่าเขียน checklist จนกลายเป็น test case
requirement เดียวกันสามารถแตกออกเป็น scenario ชุดหนึ่ง และ checklist อีกชุดหนึ่งได้
ทุก output ควร trace กลับ requirement, acceptance criteria หรือ risk ได้
ถ้าคุณเขียนสิ่งที่คนอื่นอ่านแล้ว "รู้ว่าต้องเช็กอะไรต่อ" ได้ แปลว่าคุณกำลังสร้าง test output ที่ใช้ได้จริง

← บทเรียนก่อนหน้า บทเรียนถัดไป →