CupCode.cc
Section 02 · Module 01 · Lesson 02 · ~15–20 นาที

สร้าง Test Scenario จาก Requirement

เมื่อแตก requirement ได้แล้ว ขั้นต่อไปคือการสร้าง test scenarios ที่ครอบคลุมทุกมุมมอง — ทั้ง happy path, sad path, และ edge cases

เวลาเรียน: 15–20 นาที ต้องรู้มาก่อน: Lesson 01 - แตก Requirement ออกเป็นส่วนย่อย รูปแบบ: อ่าน + แบบฝึกสั้นๆ

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

  • อธิบายความแตกต่างระหว่าง test scenario กับ test case ได้
  • สร้าง positive scenarios (happy path) จาก requirement ได้
  • สร้าง negative scenarios และ edge cases ได้
  • ใช้ scenario template ในการจัดระเบียบ scenarios
1 · Scenario vs Test Case

สองคำที่คนมักสับสน

หลายคนใช้คำว่า "test scenario" กับ "test case" สลับกันราวกับว่ามันคือสิ่งเดียวกัน แต่จริง ๆ แล้วมันอยู่คนละระดับ:

Test Scenario คือ "สถานการณ์" ระดับสูงที่ต้องการทดสอบ — เขียนเป็นประโยคสั้น ๆ หนึ่งบรรทัด:

  • "ผู้ใช้ login ด้วย email และ password ที่ถูกต้อง"
  • "ผู้ใช้ login ด้วย password ผิด 5 ครั้งติดต่อกัน"
  • "ผู้ใช้ login ด้วย email ที่ไม่มีในระบบ"

Test Case คือ "ขั้นตอนละเอียด" ที่บอกว่าต้องทำอะไร ทีละ step ในแต่ละ scenario:

  1. เปิดหน้า login
  2. กรอก email: [email protected]
  3. กรอก password: P@ssw0rd123
  4. กด "เข้าสู่ระบบ"
  5. Expected: ระบบพาไปหน้า dashboard
Test Scenario Test Case
ระดับ สูง (What to test) ละเอียด (How to test)
จำนวน 1 scenario อาจมีหลาย test cases
เขียนเมื่อไร ตอนวิเคราะห์ requirement ตอนเตรียม test execution
ใครใช้ QA Lead, ทีมทั้งหมด Tester ที่ลงมือเทสต์

ในบทนี้เราจะโฟกัสที่การสร้าง test scenarios ก่อน — ส่วน test case จะเรียนอย่างละเอียดในบทถัดไป

2 · Positive Scenarios (Happy Path)

เริ่มจากสิ่งที่ "ควรจะเป็น"

Happy path คือเส้นทางที่ผู้ใช้ทำทุกอย่างถูกต้อง ระบบทำงานได้ตามที่ออกแบบไว้ ไม่มี error ใด ๆ เกิดขึ้น

สำหรับ requirement: "ผู้ใช้สามารถลงทะเบียนได้โดยกรอก ชื่อ, email, password"

Positive scenarios:

  • TS-001: ผู้ใช้กรอกข้อมูลถูกต้องครบทุกช่อง → ลงทะเบียนสำเร็จ
  • TS-002: ผู้ใช้กรอก email ที่มีรูปแบบถูกต้อง → ระบบรับค่าได้
  • TS-003: ผู้ใช้กรอก password ที่ตรงตามเงื่อนไขความแข็งแรง → ระบบรับค่าได้

หลักการ: เขียน happy path ก่อนเสมอ เพราะถ้า happy path ยังไม่ผ่าน ก็ไม่ต้องไปเทสต์อย่างอื่น

3 · Negative Scenarios (Sad Path)

เมื่อผู้ใช้ทำสิ่งที่ "ไม่ควรจะทำ"

Negative scenarios คือสถานการณ์ที่ผู้ใช้กรอกข้อมูลผิด ทำอะไรไม่ถูกลำดับ หรือพยายามทำสิ่งที่ไม่ได้รับอนุญาต — ระบบต้องจัดการได้อย่างเหมาะสม

Negative scenarios สำหรับ requirement เดียวกัน:

  • TS-004: ผู้ใช้ไม่กรอก email → แสดง error "กรุณากรอก email"
  • TS-005: ผู้ใช้กรอก email ที่ไม่มี @ → แสดง error "รูปแบบ email ไม่ถูกต้อง"
  • TS-006: ผู้ใช้กรอก email ที่มีอยู่ในระบบแล้ว → แสดง error "email นี้ถูกใช้แล้ว"
  • TS-007: ผู้ใช้กรอก password สั้นเกินไป → แสดง error "password ต้องมีอย่างน้อย 8 ตัวอักษร"
  • TS-008: ผู้ใช้ไม่กรอกข้อมูลเลยแล้วกด submit → แสดง error ทุกช่อง

เรื่องเล่า: ทีม QA ของบริษัท fintech แห่งหนึ่งเทสต์แค่ happy path — โอนเงินสำเร็จ ยอดถูกต้อง ทุกอย่างดี แต่ไม่เคยเทสต์ว่า "ถ้าโอนเงินเกินยอดคงเหลือ" ระบบจะทำอย่างไร ผลคือวันหนึ่งผู้ใช้โอนเงินเกินยอด ระบบไม่ได้ block แต่กลับหักยอดเป็นติดลบ — ซึ่งในระบบการเงินถือเป็น critical bug ระดับรุนแรง

4 · Edge Cases

ขอบเขตที่บั๊กชอบซ่อนตัว

Edge cases คือสถานการณ์ที่อยู่ "ตรงขอบ" ของเงื่อนไข — ไม่ใช่ค่าปกติ ไม่ใช่ค่าผิดชัด ๆ แต่เป็นค่าที่อยู่ตรงจุดเปลี่ยน

ตัวอย่าง edge cases สำหรับฟอร์มลงทะเบียน:

  • TS-009: กรอกชื่อเป็นตัวอักษรตัวเดียว (เช่น "K") → ระบบรับไหม?
  • TS-010: กรอกชื่อยาว 256 ตัวอักษร → ระบบรับไหม? ตัดไหม?
  • TS-011: กรอก email ที่มี special characters เช่น [email protected] → ระบบรับไหม?
  • TS-012: กรอก password ที่ยาว 8 ตัวพอดี (ขั้นต่ำ) → ระบบรับไหม?
  • TS-013: กรอกชื่อเป็นภาษาที่มี Unicode เช่น ภาษาจีน, อาหรับ → แสดงผลถูกไหม?
  • TS-014: Copy-paste password ที่มี leading/trailing spaces → ระบบตัด space ไหม?

วิธีคิดหา edge cases:

  1. ค่าขอบ (Boundary): ค่าต่ำสุด, สูงสุด, ต่ำกว่าต่ำสุด 1, สูงกว่าสูงสุด 1
  2. ค่าว่าง (Empty): string ว่าง, null, undefined
  3. ค่าพิเศษ (Special): Unicode, emoji, HTML tags, SQL injection strings
  4. เวลา (Timing): กด submit ซ้ำ, session timeout, concurrent access
5 · Scenario Template

จัดระเบียบ Scenarios ให้เป็นระบบ

เมื่อคุณมี scenarios จำนวนมาก ควรจัดเป็นกลุ่มด้วย template:

Scenario ID ประเภท Feature สถานการณ์ Expected Result
TS-001 Positive Registration กรอกข้อมูลถูกต้องครบ ลงทะเบียนสำเร็จ, ไปหน้า welcome
TS-004 Negative Registration ไม่กรอก email แสดง error "กรุณากรอก email"
TS-009 Edge Registration ชื่อ 1 ตัวอักษร ระบบรับค่าได้

การจัดกลุ่มช่วยให้:

  • เห็นว่า feature ไหนยังขาด scenario ประเภทไหน
  • ทำ test prioritization ได้ง่าย (เทสต์ positive ก่อน, แล้ว negative, แล้ว edge)
  • review กับทีมได้ง่าย — ทุกคนเห็นภาพรวม
Practice

แบบฝึก: สร้าง Test Scenarios จาก Login/Registration Requirement

Requirement:

"ระบบต้องให้ผู้ใช้สามารถ login ด้วย email และ password ได้ ถ้ากรอกผิดเกิน 5 ครั้ง ระบบจะล็อกบัญชี 30 นาที ผู้ใช้สามารถขอ reset password ผ่าน email ได้"

  1. เขียน positive scenarios อย่างน้อย 3 ข้อ

    ดูคำตอบแนะนำ
    • TS-001: ผู้ใช้กรอก email และ password ที่ถูกต้อง → login สำเร็จ ไปหน้า dashboard
    • TS-002: ผู้ใช้กด "ลืมรหัสผ่าน" กรอก email ที่มีในระบบ → ได้รับ email reset password
    • TS-003: ผู้ใช้คลิก link reset password จาก email → ไปหน้าตั้ง password ใหม่ได้
    • TS-004: ผู้ใช้ตั้ง password ใหม่ที่ตรงตามเงื่อนไข → เปลี่ยนสำเร็จ login ด้วย password ใหม่ได้

  2. เขียน negative scenarios อย่างน้อย 4 ข้อ

    ดูคำตอบแนะนำ
    • TS-005: ผู้ใช้กรอก password ผิด → แสดง error "email หรือ password ไม่ถูกต้อง" (ไม่บอกว่าอันไหนผิด)
    • TS-006: ผู้ใช้กรอก email ที่ไม่มีในระบบ → แสดง error เดียวกัน (เพื่อความปลอดภัย)
    • TS-007: ผู้ใช้กรอก password ผิด 5 ครั้งติดต่อกัน → บัญชีถูกล็อก แสดงข้อความว่าถูกล็อก 30 นาที
    • TS-008: ผู้ใช้พยายาม login ขณะบัญชีถูกล็อก → แสดง error "บัญชีถูกล็อก กรุณารออีก XX นาที"
    • TS-009: ผู้ใช้กด reset password ด้วย email ที่ไม่มีในระบบ → ไม่ส่ง email แต่แสดงข้อความเดียวกัน (security)

  3. เขียน edge cases อย่างน้อย 3 ข้อ

    ดูคำตอบแนะนำ
    • TS-010: ผู้ใช้กรอก password ผิด 4 ครั้ง แล้วกรอกถูกในครั้งที่ 5 → login สำเร็จ, ตัวนับ reset
    • TS-011: บัญชีถูกล็อกแล้ว ผู้ใช้ขอ reset password → ควรทำได้ (reset password ไม่ควรถูก block)
    • TS-012: ผู้ใช้ใช้ reset password link หลังผ่านไป 24 ชั่วโมง → link หมดอายุ ใช้ไม่ได้
    • TS-013: ผู้ใช้เปิดหน้า login พร้อมกัน 2 tab แล้ว login ทั้ง 2 tab → ระบบจัดการ session อย่างไร?
    • TS-014: ผู้ใช้กรอก email ด้วยตัวพิมพ์ใหญ่ ([email protected]) → ควร login ได้เหมือนกับ [email protected]

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

  • Test Scenario คือ "อะไรที่จะเทสต์" (What) ส่วน Test Case คือ "เทสต์อย่างไร" (How)
  • เริ่มจาก positive scenarios (happy path) เสมอ — ถ้า happy path ไม่ผ่าน ไม่ต้องไปต่อ
  • Negative scenarios คือหัวใจของ QA — เพราะผู้ใช้จริงจะทำสิ่งที่คุณคาดไม่ถึงเสมอ
  • Edge cases คือจุดที่บั๊กซ่อนตัว — ค่าขอบ, ค่าว่าง, ค่าพิเศษ, ปัญหาเรื่องเวลา
  • ใช้ scenario template จัดระเบียบเพื่อให้เห็นช่องว่างและทำ prioritization ได้ง่าย
← บทเรียนก่อนหน้า บทเรียนถัดไป →