State Transition Testing

พฤติกรรมเปลี่ยนตาม "สถานะ"

ลองนึกถึงตู้ ATM — ถ้าคุณกดรหัสผิดครั้งแรก ระบบจะบอกว่า "กรุณาลองอีกครั้ง" แต่ถ้ากดผิดครั้งที่สาม ระบบจะกลืนบัตร input เหมือนกัน (รหัสผิด) แต่ผลลัพธ์ต่างกัน เพราะ "สถานะ" ของระบบเปลี่ยนไปแล้ว

ระบบแบบนี้มีอยู่ทุกที่:

• Order status: Pending → Confirmed → Shipped → Delivered
• User account: Active → Suspended → Deactivated
• Login: ถูก → ผิดครั้งที่ 1 → ผิดครั้งที่ 2 → ล็อก
• Bug tracking: New → Assigned → In Progress → Fixed → Verified → Closed

EP, BVA, และ Decision Table ไม่มีเครื่องมือจัดการ "สถานะ" — State Transition Testing ถูกออกแบบมาเพื่อเรื่องนี้โดยเฉพาะ

4 สิ่งที่ต้องรู้จัก

States (สถานะ): สถานะที่ระบบอยู่ ณ เวลาหนึ่ง

• เช่น: "รอชำระเงิน", "ชำระแล้ว", "กำลังจัดส่ง"

Transitions (การเปลี่ยนสถานะ): การย้ายจากสถานะหนึ่งไปอีกสถานะ

• เช่น: "รอชำระเงิน" → "ชำระแล้ว"

Events (เหตุการณ์): สิ่งที่ทำให้เกิด transition

• เช่น: "ลูกค้ากดชำระเงิน" ทำให้เปลี่ยนจาก "รอชำระ" เป็น "ชำระแล้ว"

Guards/Conditions (เงื่อนไข): เงื่อนไขที่ต้องเป็นจริงเพื่อให้ transition เกิดขึ้น

• เช่น: "ชำระเงินสำเร็จ" (ถ้าไม่สำเร็จ จะไม่เปลี่ยนสถานะ)

วาดภาพให้เห็น Flow

ตัวอย่าง: Order Status Flow

[New] --(ลูกค้ายืนยัน)--> [Confirmed]
[Confirmed] --(ชำระเงิน)--> [Paid]
[Confirmed] --(ยกเลิก)--> [Cancelled]
[Paid] --(จัดส่ง)--> [Shipped]
[Paid] --(ขอคืนเงิน)--> [Refunded]
[Shipped] --(ลูกค้าได้รับ)--> [Delivered]
[Shipped] --(สินค้าสูญหาย)--> [Lost]
[Delivered] --(ขอคืนสินค้า ภายใน 7 วัน)--> [Return Requested]
[Return Requested] --(อนุมัติ)--> [Refunded]
[Return Requested] --(ปฏิเสธ)--> [Delivered]

States: New, Confirmed, Paid, Shipped, Delivered, Cancelled, Refunded, Lost, Return Requested Events: ยืนยัน, ชำระเงิน, ยกเลิก, จัดส่ง, ขอคืนเงิน, ได้รับ, สูญหาย, ขอคืนสินค้า, อนุมัติ, ปฏิเสธ

จัดข้อมูลเป็นตาราง

จาก table นี้ แต่ละแถว = 1 test case

สิ่งที่ "ไม่ควรเกิดขึ้น" แต่ต้องเทสต์

Invalid transitions คือการเปลี่ยนสถานะที่ไม่ควรเป็นไปได้ — ระบบต้อง block ไม่ให้เกิด:

เรื่องเล่า: ระบบ e-commerce แห่งหนึ่งมีบั๊กที่ลูกค้าสามารถ "ขอคืนเงิน" จาก order ที่อยู่ในสถานะ "Cancelled" ได้ ทำให้ได้เงินคืนทั้งที่ไม่เคยจ่าย เพราะทีม dev ลืม validate ว่า "Cancelled" ไม่ควรมี transition ไปที่ "Refunded"

Invalid transitions เป็นสิ่งที่ QA ต้องเทสต์เสมอ — เพราะมันคือช่องทางที่ hacker หรือบั๊กจะใช้ทำให้ระบบอยู่ใน "สถานะที่เป็นไปไม่ได้"

Valid + Invalid = ครอบคลุม

Valid transition tests: เทสต์ทุก transition ที่ถูกต้อง

• TC-ST-001: New → Confirmed (ลูกค้ายืนยัน)
• TC-ST-002: Confirmed → Paid (ชำระเงินสำเร็จ)
• TC-ST-003: Confirmed → Cancelled (ยกเลิก)
• ...ทุก transition ใน table

Invalid transition tests: เทสต์ transitions ที่ไม่ควรเกิด

• TC-ST-011: New → Shipped (ควร error)
• TC-ST-012: Cancelled → Paid (ควร error)
• ...สิ่งที่ "ไม่ควรเกิด"

Sequence tests: เทสต์ลำดับ transitions ติดต่อกัน

• TC-ST-021: New → Confirmed → Paid → Shipped → Delivered (happy path ครบวงจร)
• TC-ST-022: New → Confirmed → Cancelled (ยกเลิกก่อนชำระ)
• TC-ST-023: New → Confirmed → Paid → Shipped → Delivered → Return Requested → Refunded