จาก Acceptance Criteria สู่ Test Conditions

สามชั้นที่ค่อย ๆ ลงจาก "ความต้องการ" ไปสู่ "สิ่งที่ต้องพิสูจน์"

หลายทีมใช้สามคำนี้ปนกันจนทำให้การสื่อสารงงง่ายมาก ลองแยกให้ชัดแบบนี้:

จำสั้น ๆ แบบนี้ได้

• Requirement = สิ่งที่อยากได้
• Acceptance Criteria = เงื่อนไขที่บอกว่า "ทำถูกแล้ว"
• Test Condition = รายการที่เราต้องพิสูจน์ว่า criteria นั้นจริง

ทำไม QA ต้องแยกให้ออก

ถ้าคุณกระโดดจาก requirement ไปเขียน test case ทันที คุณมักจะ:

• ข้าม business rule ที่ซ่อนอยู่
• ทดสอบแค่ flow ปกติ
• ไม่รู้ว่าจริง ๆ แล้วตัวเองกำลังพิสูจน์ criteria ข้อไหน

แต่ถ้าคุณแยกผ่านชั้น test condition ก่อน คุณจะได้ "coverage map" ว่าต้องพิสูจน์อะไรบ้าง แล้วค่อยเลือกว่าจะเขียนเป็น scenario, case หรือ checklist ต่อ

มองหา 5 ชิ้นส่วนก่อนเสมอ

เวลาเห็น acceptance criteria 1 ข้อ ลองแยกให้ได้อย่างน้อย 5 อย่างนี้:

สัญญาณว่า criteria ยังแตกต่อไม่ได้

ถ้าคุณอ่าน criteria แล้วตอบคำถามพวกนี้ไม่ได้ แปลว่ายังไม่พร้อมพอ:

• ข้อมูลที่ใช้ตัดสินมีอะไรบ้าง?
• สิ่งที่ถือว่า "ผ่าน" คืออะไรแน่?
• ถ้าไม่ผ่าน ต้องแสดงอะไร?
• มีขอบเขตตัวเลข, เวลา, จำนวนครั้ง, หรือสถานะไหนเกี่ยวข้องไหม?

ตัวอย่าง criteria ที่ยังเบลอ:

คำว่า "ถูกต้อง" ยังรวมอะไรบ้าง?

• format ถูก?
• มีอยู่ในระบบ?
• ยังไม่หมดอายุ?
• ยังไม่ถูกใช้เกิน quota?
• ใช้กับสินค้านี้ได้?
• ยอดถึงขั้นต่ำ?

คำเดียวอาจซ่อน test conditions ได้เป็นสิบข้อ

อย่าคิดแค่ Positive, Negative, Boundary อย่างเดียว ให้มอง Alternate Path ด้วย

บทเรียนพื้นฐานมักสอน 3 มุมคือ positive, negative, boundary ซึ่งถูกต้องและยังสำคัญมาก แต่ในชีวิตจริงคุณควรนึกถึง alternate path ด้วย

ทำไม Alternate Path สำคัญ

หลายครั้ง bug ไม่ได้อยู่ที่ "ผิด" หรือ "ขอบ" แต่เกิดตอนผู้ใช้เปลี่ยน flow ระหว่างทาง เช่น:

• ใส่คูปองแล้วกลับไปแก้ตะกร้า
• จ่ายเงินไม่สำเร็จแล้วกลับมาลองใหม่
• ขอ reset password ซ้ำก่อนลิงก์เดิมหมดอายุ

สิ่งเหล่านี้ไม่ใช่ happy path และไม่ใช่ invalid input ตรง ๆ แต่เป็น flow ที่ระบบต้องรับให้ถูก

แตก acceptance criteria จริงทีละขั้น

ลองดูตัวอย่างนี้

ขั้นที่ 1: หาเงื่อนไขหลักในประโยค

จาก criteria นี้ เราพอเห็นกฎหลัก 3 ก้อน:

1. สมัครได้ถ้า email ใช้งานได้
2. reject ถ้า format ผิด
3. reject ถ้า email ซ้ำ

แต่ถ้าหยุดแค่นี้ coverage ยังบางมาก เพราะแต่ละก้อนยังมีรายละเอียดซ่อนอยู่

ขั้นที่ 2: ขยายคำที่กว้างเกินไป

คำว่า "format ผิด" อาจแตกย่อยได้อีก เช่น:

• ไม่มี @
• ไม่มี domain
• มีช่องว่างกลางข้อความ
• ว่างเปล่า
• ยาวเกิน limit
• มีอักขระที่ไม่อนุญาต

คำว่า "ซ้ำ" ก็ยังไม่ชัด:

• ซ้ำแบบ case-insensitive หรือไม่?
• ถ้ามี account เดิมแต่ถูก deactivate แล้วนับเป็นซ้ำไหม?
• ถ้าเคยสมัครแต่ยังไม่ verify ล่ะ?

ขั้นที่ 3: แตกเป็น test conditions

Positive

1. Email format ถูกและยังไม่มีในระบบ → สมัครสำเร็จ
2. Email format ถูกและมีตัวพิมพ์ใหญ่/เล็กผสมกัน → สมัครสำเร็จถ้านโยบายรองรับ
3. Email แบบ plus addressing เช่น [email protected] → สมัครสำเร็จถ้าระบบรองรับ

Negative: Validation

4. ไม่มี @
5. มี @ แต่ไม่มี domain
6. มีช่องว่างต้น/ท้าย
7. มีช่องว่างตรงกลาง
8. ว่างเปล่า
9. ยาวเกิน limit ที่ระบบกำหนด

Negative: Business Rule

10. Email มีอยู่ในระบบแล้ว
11. Email ซ้ำแบบต่างกันแค่ตัวพิมพ์ใหญ่/เล็ก
12. Email เคยสมัครแต่ account ถูก soft-delete
13. Email เคยสมัครแต่ยังไม่ verify

Boundary

14. Email ความยาวต่ำสุดที่ยัง valid
15. Email ความยาวสูงสุดที่ยัง valid
16. Email ยาวเกินสูงสุด 1 ตัวอักษร

Alternate Path

17. ผู้ใช้แก้ email จากค่าผิดเป็นค่าถูกก่อนกด submit
18. ผู้ใช้ submit ซ้ำสองครั้งเพราะเน็ตช้า

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

criteria เดียวกัน ถ้าอ่านแบบผิวเผินจะได้ 2–3 conditions แต่ถ้าอ่านแบบนักทดสอบ คุณอาจได้ 15–20 conditions โดยไม่ต้อง "คิดเยอะเกินเหตุ" แค่ไม่ปล่อยคำกว้าง ๆ ผ่านไปเฉย ๆ

บาง criteria ไม่ได้ซ่อนแค่ validation แต่ซ่อน logic ของธุรกิจ

criteria นี้มีทั้ง:

• จำนวนครั้ง
• ช่วงเวลา
• สถานะการล็อก
• เงื่อนไขการปลดล็อก

แตกเป็น test conditions แบบมีเหตุผล

Positive / Expected Behavior

1. Login ผิด 4 ครั้งใน 10 นาที → ยังไม่ล็อก
2. Login ผิด 5 ครั้งติดใน 10 นาที → ล็อกบัญชี
3. หลังล็อกครบ 30 นาที → login ได้อีกครั้ง

Boundary

4. ผิด 5 ครั้งใน 9 นาที 59 วินาที → ล็อก
5. ผิด 5 ครั้งใน 10 นาที 01 วินาที → ไม่ล็อก ถ้ากฎกำหนด "ภายใน 10 นาที"
6. ครบ 29 นาที 59 วินาที → ยังล็อก
7. ครบ 30 นาที 00 วินาที → ปลดล็อก

Alternate Path

8. Login ผิด 4 ครั้ง แล้วครั้งที่ 5 เป็น login ถูก → reset counter หรือไม่?
9. ล็อกแล้วผู้ใช้กด "forgot password" → ทำได้ไหม?
10. Admin ปลดล็อกก่อนครบ 30 นาที → สถานะต้องเปลี่ยนทันที

Negative / Security

11. พยายาม login ตอน account ถูกล็อก → ต้องแสดงข้อความที่เหมาะสม
12. account ที่ไม่มีอยู่จริงถูกยิง request ซ้ำ ๆ → ระบบนับเหมือน account ปกติไหม?
13. นับต่อ account หรือต่อ IP ถ้ามาจากหลายอุปกรณ์?

สิ่งที่ criteria นี้สอนเรา

test condition ไม่ได้มีไว้แค่แตก input ผิดหรือถูก แต่มีไว้จับ:

• state transition
• timing rules
• alternate flow
• security behavior

ไม่ต้องแตกทุกอย่างเท่ากัน แต่ต้องแตกให้เหมาะกับความเสี่ยง

หลายคนพอเริ่มแตก conditions แล้วกลัวว่าจะเยอะเกินไป คำตอบคือ:

ลองใช้ 3 คำถามนี้ช่วยตัดสิน:

1. ถ้าพลาด condition นี้ จะกระทบธุรกิจหรือผู้ใช้มากไหม?
2. condition นี้เป็นจุดที่ระบบมักพังบ่อยหรือไม่?
3. ถ้าไม่เขียน condition นี้ ทีมมีโอกาสลืมหรือเข้าใจไม่ตรงกันไหม?

ตัวอย่างการจัด priority

การจัด priority ช่วยให้เวลาจำกัด คุณยังรู้ว่าจะต้องทดสอบอะไรก่อน

ไม่ต้องสวย แต่ต้องเชื่อม criteria กับสิ่งที่ต้องพิสูจน์ได้

ตัวอย่าง template แบบเรียบง่าย:

ตัวอย่างกรอกจริง

• แตกจาก UI ก่อนแตกจากกฎธุรกิจ ทำให้ได้แต่เคสคลิกปุ่ม
• เขียน condition กว้างเกิน เช่น "ทดสอบ email invalid" โดยไม่แยกชนิดของ invalid
• ลืม alternate path เช่น กดซ้ำ, กลับไปแก้ข้อมูล, retry
• ลืม boundary ที่ผูกกับตัวเลข เวลา และจำนวนครั้ง
• เขียนซ้ำกับ acceptance criteria แบบ copy มาเฉย ๆ โดยยังไม่บอกว่า "จะทดสอบอะไรบ้าง"

ถ้าเผลอทำแบบนี้ ให้ย้อนกลับไปถามตัวเองว่า:

ถ้าไม่ แปลว่ามันยังไม่ใช่ test condition ที่ดีพอ