End-to-End Tests
End-to-end หรือ E2E test จำลองการใช้งานใกล้กับผู้ใช้จริงที่สุด โดยเดินตั้งแต่ต้น flow ไปจนถึงผลลัพธ์สุดท้ายเพื่อเช็กว่าเส้นทางสำคัญของระบบยังทำงานได้ครบ
ครอบคลุมมาก แต่ก็แพงกว่า
E2E ช่วยสร้างความมั่นใจใน user journey สำคัญได้ดีมาก แต่ช้ากว่า เปราะกว่า และดูแลยากกว่าระดับอื่น
มันคืออะไร
E2E test จำลองมุมมองของผู้ใช้จริง เช่น เปิดหน้า กรอกฟอร์ม กดปุ่ม และตรวจผลลัพธ์ปลายทาง ทำให้เราเห็นว่าระบบทั้งเส้นทางยังทำงานร่วมกันได้ในภาพใหญ่
พิสูจน์อะไรได้ / พิสูจน์อะไรไม่ได้
E2E test ให้ความมั่นใจสูงสุดในระดับ flow จริง แต่ไม่เหมาะกับการใช้แทน test ทุกระดับ เพราะช้าและบอกสาเหตุปัญหาได้ไม่เร็วเท่า unit หรือ integration
Point 1
พิสูจน์ได้: critical user journeys เช่น sign in, checkout, submit form
Point 2
พิสูจน์ได้: การทำงานร่วมกันของระบบตั้งแต่ต้นจนจบในมุมผู้ใช้
Point 3
พิสูจน์ไม่ได้ดีนัก: ต้นตอของ bug ระดับเล็กหรือ feedback เร็วสำหรับทุกเคสย่อย
เหมาะใช้เมื่อไร
ใช้ E2E กับเส้นทางที่ถ้าพังแล้วกระทบผู้ใช้หรือธุรกิจโดยตรง เช่น การสมัครสมาชิก การสั่งซื้อ หรือการนำทางหลักของโปรดักต์ ไม่จำเป็นต้องทำกับทุก interaction ย่อย
- เลือกเฉพาะ user journey ที่สำคัญจริง
- ใช้เป็น safety net ของ flow หลักก่อน release
- อย่าใช้ E2E แทน unit และ integration ทั้งหมด
- ถ้ามีมากเกินไป feedback จะช้าและค่าใช้จ่ายในการดูแลจะสูงขึ้น
Practice
ลองออกแบบ test case
ลองคิดในมุมผู้ใช้จริงว่า flow นี้ควรถูกทดสอบแบบ E2E อย่างไร
โจทย์
ผู้ใช้ใหม่เปิดหน้าเว็บ สมัครสมาชิก ยืนยันตัวตน แล้วเข้าสู่หน้า dashboard ได้สำเร็จ
ลองคิดก่อน
- จุดเริ่มต้นและจุดจบของ flow นี้คืออะไร
- ขั้นตอนสำคัญไหนที่ห้ามพัง
- มีกรณีไหนที่ควรมี E2E ทดสอบเพิ่มนอกจาก happy path
ดูแนวคิดเฉลย
- ควรมี happy path ตั้งแต่เปิดหน้า signup กรอกข้อมูล submit จน redirect ไป dashboard
- ควร test ว่าหลังสมัครสำเร็จ ผู้ใช้เห็นข้อมูลหรือ UI ที่ยืนยันว่าล็อกอินแล้ว
- ควรมีกรณี fail สำคัญ เช่น สมัครด้วยอีเมลที่ถูกใช้แล้ว หรือยืนยันตัวตนไม่สำเร็จ
- ควรเลือกเฉพาะ flow ที่กระทบผู้ใช้หรือธุรกิจโดยตรง ไม่ต้องทำ E2E กับ interaction ย่อยทุกปุ่ม