การสมดุลระดับการทดสอบ

เลือกระดับที่ต่ำที่สุดที่ยังพิสูจน์ความเสี่ยงนั้นได้

เวลาเจอ requirement หรือ test idea ใหม่ อย่าเริ่มจากคำถามว่า:

• “เขียน E2E ได้ไหม”

ให้เริ่มจาก:

• “เรากำลังพยายามพิสูจน์อะไร”
• “ปัญหานี้จับได้ในระดับที่ถูกกว่านี้ไหม”

ตัวอย่าง:

• ถ้ากำลังพิสูจน์สูตรคำนวณส่วนลด ใช้ unit test ก็พอ
• ถ้ากำลังพิสูจน์ว่า API คุยกับ database ถูก ใช้ integration test เหมาะกว่า
• ถ้ากำลังพิสูจน์ว่า user ซื้อของจบจริง ใช้ E2E จึงจะครบ

หลักนี้ช่วยให้เราไม่ใช้ค้อนใหญ่กับทุกปัญหา

มันเก่งมากกับ logic รายส่วน แต่ไม่เก่งกับโลกจริงที่เชื่อมกันหลายจุด

unit test เหมาะมากเมื่อ:

• มี input/output ชัด
• dependency น้อย
• อยาก feedback เร็ว

แต่สิ่งที่มันมองไม่เห็นคือ:

• การ map data ผิด format ระหว่างชั้น
• config ผิด
• query จริงไม่ตรงกับที่ mock ไว้
• integration กับ third-party ที่มี behavior ต่างจาก stub

ดังนั้น unit เยอะไม่แปลว่าระบบทั้งก้อนปลอดภัยแล้ว

เพราะมันแพงกว่า unit ไม่มาก แต่จับปัญหาที่เจอบ่อยในงานจริงได้เยอะ

integration test เหมาะกับสถานการณ์แบบนี้:

• API เรียกฐานข้อมูลแล้วคืนค่า JSON
• service หนึ่ง publish event แล้วอีก service รับไปทำงานต่อ
• frontend เรียก backend แล้วต้อง parse response ให้ถูก
• ระบบส่ง request ไป payment/email provider

สิ่งที่ integration test มักจับได้ดี:

• schema mismatch
• transaction ไม่ครบ
• query ผิด
• error handling ไม่ตรง
• configuration ผิด

หลายทีมลด production bugs ได้เยอะไม่ใช่เพราะเพิ่ม E2E แต่เพราะเพิ่ม integration ในจุดที่สำคัญ

ใช้กับสิ่งที่ต้องพิสูจน์จากมุมผู้ใช้หรือข้ามหลายชั้นพร้อมกัน

E2E ควรถูกใช้กับ:

• login / registration
• checkout / payment
• order placement
• reset password
• flow ที่รายได้หรือความเชื่อมั่นของผู้ใช้ขึ้นอยู่กับมัน

นอกจากนี้ E2E ยังเหมาะเมื่อ:

• ต้องเช็ก behavior บน browser จริง
• มีหลายหน้าหรือหลาย service ต่อกัน
• มี state เปลี่ยนไปตลอด flow

แต่ไม่ควรใช้ E2E ไปตรวจ logic ย่อย ๆ ที่ unit หรือ integration จับได้ถูกกว่าและเร็วกว่า

มันไม่แทน integration หรือ E2E ทั้งหมด แต่ช่วยปิดช่องว่างบางจุดได้ดีมาก

contract test เน้นเช็กว่า “ผู้ให้บริการ” และ “ผู้เรียกใช้” ยังเข้าใจรูปแบบข้อมูลตรงกันอยู่ไหม

เหมาะกับ:

• microservices
• frontend-backend ที่พึ่ง schema ชัด
• integration กับ third-party ที่มี contract แน่นอน

ข้อดี:

• เร็วกว่า E2E
• ชี้ปัญหาที่ interface ได้ไว
• ไม่ต้องยก environment ใหญ่ขึ้นมาทุกครั้ง

ข้อจำกัด:

• ไม่ได้พิสูจน์ user flow เต็ม
• ไม่ได้แทนการทดสอบ business flow จากต้นจนจบ

ลองถามว่าเราอยากลดความเสี่ยงแบบไหน

ใช้คำถาม 4 ข้อนี้ช่วยกรอง

1. สิ่งที่เราจะพิสูจน์เป็น logic รายส่วน หรือเป็นการเชื่อมกันหลายชั้น
2. ถ้า fail เราอยากรู้ปัญหาเร็วแค่ไหน
3. จำเป็นต้องใช้ browser จริงหรือ UI จริงหรือไม่
4. ถ้าใช้ระดับแพงกว่า เราได้ความมั่นใจเพิ่มจริงไหม

ถ้าคำตอบข้อ 4 คือ “ไม่มาก” ให้ถอยลงมาระดับที่ถูกกว่า