Unit​ ​Test​,​ ​Integration​ ​Test​ ​และ​ ​End​-​to​-​End​ ​Test​ ​ต่าง​กัน​อย่างไร

Unit Test ตรวจหน่วยเล็กที่แยกได้ เช่น กฎคำนวณ Integration Test ตรวจว่าหลายส่วนทำงานร่วมกัน เช่น API กับฐานข้อมูล End-to-End (E2E) Test ตรวจเส้นทางที่ผู้ใช้ทำผ่านระบบเกือบครบ ความต่างคือขอบเขตและชนิดความเสี่ยงที่ตรวจ ไม่ใช่ว่าระดับสูงกว่าดีกว่าทุกกรณี

ตัวอย่างงานเดียวกันสามระดับ

ระบบคำสั่งซื้ออาจมี Unit Test ว่าส่วนลดไม่ทำให้ยอดติดลบ Integration Test ว่า POST /orders บันทึกรายการและตัดสต็อกในธุรกรรม และ E2E Test ว่าผู้ใช้เลือกสินค้า ยืนยัน แล้วเห็นเลขคำสั่งซื้อ การมี Unit Test ผ่านไม่พิสูจน์ว่า Route ต่อฐานข้อมูลถูก ส่วน E2E ผ่านหนึ่งกรณีก็ไม่ครอบคลุมทุกสูตรส่วนลด

ภาพที่ 1: ใช้ระดับที่เล็กที่สุดซึ่งตรวจความเสี่ยงนั้นได้ และเพิ่มระดับสูงเมื่อจำเป็นต้องพิสูจน์การเชื่อมต่อ

ข้อแลกเปลี่ยน

Unit Test มักเร็วและชี้จุดผิดง่าย แต่ไม่เห็นการเชื่อม Integration Test เห็นสัญญาระหว่างส่วนและฐานข้อมูลจริงมากขึ้น แต่ต้องจัดสภาพแวดล้อม E2E ให้ความมั่นใจต่อเส้นทางผู้ใช้ แต่ช้าหรือเปราะเมื่อหน้าจอเปลี่ยนบ่อย จึงไม่ควรเขียน E2E ซ้ำทุกกรณีที่ Unit ตรวจได้แล้ว

วิธีเลือกตามระบบ

เริ่มจากกฎสำคัญและจุดเชื่อมที่เคยมีปัญหา ทำ Test ที่เสียเมื่อพฤติกรรมผิด ไม่ใช่ Test ที่ยืนยันรายละเอียดการเขียนโค้ดภายใน หากระบบพึ่ง API ภายนอก ให้มีการทดสอบสัญญาและกรณีปลายทางล่มตามความเสี่ยง ไม่เชื่อว่าการ Mock อย่างเดียวพิสูจน์ระบบจริงได้

สำหรับรายงาน

ทำตารางสามระดับ ระบุสิ่งที่ทดสอบ ข้อมูลเข้า ผลที่คาด สิ่งที่ยังตรวจไม่ได้ และสภาพแวดล้อมที่ใช้ ชี้ว่าหนึ่ง Requirement ต้องมี Test ระดับใดบ้าง แทนการรายงานจำนวน Test โดยไม่บอกคุณค่า

อ่าน Software Testing และ Regression Testing หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

ลองกำหนดกรณีศึกษาเป็น ฟีเจอร์คำนวณยอด Order ผ่าน API และหน้าเว็บ และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้

หลักฐานที่ควรแสดงคือ Unit ของสูตรคำนวณ Integration กับ DB และ E2E การสั่งซื้อ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

เกณฑ์ประเมินตัวอย่างคือ ข้อผิดพลาดแต่ละระดับตรวจเจอในระดับที่เหมาะ ส่วนข้อจำกัดที่ต้องระบุคือ E2E มากเกินไปทำให้รันช้าและวิเคราะห์สาเหตุยาก หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน

แหล่งข้อมูลประกอบ

• The Practical Test Pyramid — การแบ่งระดับและข้อแลกเปลี่ยนของการทดสอบ