Section 03 · Module 03 · Lesson 01 · ~20–24 นาที

Test Pyramid ของ Mike Cohn

automation ที่ดีไม่ใช่แค่มี test เยอะ แต่ต้องวางสัดส่วนให้เหมาะกับต้นทุน ความเร็ว และความเสี่ยงของแต่ละระดับ บทนี้จะช่วยให้คุณเห็นภาพว่าทำไมหลายทีมพังเพราะมี E2E เยอะเกินไป และควรสร้างฐานอย่างไรให้ suite อยู่ได้ระยะยาว

เวลาเรียน: 20–24 นาที ต้องรู้มาก่อน: Module 02 - การเลือกสิ่งที่ควร automate รูปแบบ: อ่าน + เปรียบเทียบสัดส่วน + แบบฝึกวิเคราะห์

จบบทนี้แล้วคุณจะ...

อธิบายภาพรวมของ Test Pyramid ได้ว่าแต่ละชั้นมีหน้าที่ต่างกันอย่างไร
เข้าใจว่าทำไมฐานที่กว้างกว่าด้านบนถึงช่วยให้ suite เร็วและเสถียรกว่า
แยก anti-patterns อย่าง ice cream cone และ hourglass ได้
เชื่อมโยงแต่ละระดับกับต้นทุน ความเร็ว และชนิดของบั๊กที่มักจับได้
ใช้ pyramid เป็นกรอบคิดเวลาออกแบบ automation strategy ได้

1 · Test Pyramid คือกรอบคิดเรื่อง “สัดส่วน”

มันไม่ได้บอกว่าต้องมีจำนวนเท่าไรเป๊ะ ๆ แต่บอกว่าควรเอาแรงไปลงตรงไหนมากกว่า

แนวคิดจาก Mike Cohn แบ่ง automated tests ออกเป็น 3 ชั้นหลัก:

ระดับ	ทดสอบอะไร	จุดเด่น	จำนวนโดยทั่วไป
Unit	logic ของฟังก์ชัน, class, module	เร็วและเสถียรที่สุด	มากที่สุด
Integration	การทำงานร่วมกันระหว่างส่วนต่าง ๆ	จับปัญหาที่จุดเชื่อมต่อได้ดี	ปานกลาง
E2E / UI	flow จากมุมผู้ใช้	เห็นภาพจริงที่สุด	น้อยที่สุด

คำว่า “พีระมิด” จึงไม่ได้สำคัญที่รูป แต่สำคัญที่หลักการว่า:

ของที่ถูกและเร็ว ควรมีเยอะ
ของที่แพงและเปราะ ควรมีเท่าที่จำเป็น

2 · ทำไมฐานต้องกว้าง

เพราะทีมต้องการ feedback เร็วทุกวัน ไม่ใช่แค่ก่อน release

ลองเทียบให้เห็นภาพ:

ระดับ	เวลาเขียน	เวลารัน	โอกาส flaky	สิ่งที่มักจับได้
Unit	ต่ำ	เร็วมาก	ต่ำมาก	logic ผิด, edge cases
Integration	กลาง	เร็วพอใช้	ต่ำถึงกลาง	contract ผิด, data flow ผิด
E2E	สูง	ช้า	กลางถึงสูง	flow หลักพัง, wiring ระดับระบบ

ถ้าทีมมี unit และ integration ที่ดี:

dev รู้เร็วว่าพังตรงไหน
debug ง่ายกว่า
CI ไม่ช้าเกินไป
E2E ไม่ต้องรับภาระทุกอย่าง

แต่ถ้าฐานบางมาก ทีมจะเริ่มผลักทุกอย่างไปตรวจที่ UI ซึ่งเป็นระดับที่แพงที่สุด

3 · ทำความเข้าใจแต่ละชั้นให้ชัด

จะได้ไม่เผลอใช้ระดับผิดงาน

Unit Tests

เหมาะกับ:

ฟังก์ชันคำนวณราคา
validation logic
data mapping
business rules ที่มี input/output ชัด

ข้อดีคือเร็วและ pinpoint ปัญหาได้ดีมาก แต่ไม่เห็นว่าระบบภายนอกเชื่อมกันถูกหรือไม่

Integration Tests

เหมาะกับ:

API กับ database ทำงานร่วมกัน
service A ส่งข้อมูลให้ service B
frontend เรียก backend แล้วรับโครงสร้างข้อมูลถูก

ชั้นนี้มักเป็น “sweet spot” เพราะจับบั๊กสำคัญได้มากกว่าที่หลายทีมคาด แต่ต้นทุนยังไม่สูงเท่า E2E

E2E Tests

เหมาะกับ:

login
checkout
payment
registration
flow สำคัญที่ผู้ใช้ต้องใช้งานได้จริงตั้งแต่ต้นจนจบ

E2E จำเป็น แต่ไม่ควรกลายเป็นชั้นหลักของ suite

4 · ถ้าไม่เป็นพีระมิด จะเกิดอะไรขึ้น

anti-pattern แต่ละแบบพาทีมเจ็บคนละทาง

Ice Cream Cone

ลักษณะ:

E2E เยอะมาก
unit น้อย
integration แทบไม่มี

มักเกิดเมื่อทีมเอา manual test cases มาแปลงเป็น UI scripts ตรง ๆ

ผลเสีย:

รันช้า
flaky เยอะ
maintain ยาก
fail แล้วหาสาเหตุช้า

Hourglass

ลักษณะ:

unit เยอะ
integration น้อยมาก
E2E ก็ยังเยอะ

ผลเสีย:

logic รายส่วนดูดี
user flow บางส่วนก็มี E2E คุม
แต่ปัญหาตรงจุดเชื่อมระหว่างบริการหรือชั้นข้อมูลยังหลุดได้บ่อย

5 · ตัวอย่างจากระบบจริง

ทีม e-commerce มักพังตรงไหนถ้าสัดส่วนไม่สมดุล

สมมติระบบมี:

คำนวณส่วนลด
สต็อกสินค้า
checkout
payment callback
อีเมลยืนยันคำสั่งซื้อ

การวาง pyramid แบบมีเหตุผลอาจเป็น:

unit tests จำนวนมากกับ pricing rules, tax rules, coupon validation
integration tests กับ cart-to-order, payment callback, DB persistence
E2E tests เฉพาะ smoke flows เช่น guest checkout, member checkout, payment success/fail

ถ้าทีมข้าม unit/integration แล้วไปทุ่มกับ UI:

bug เรื่องคำนวณราคาอาจต้องไปรอเจอใน E2E
payment fail อาจ debug ยากมาก
suite ช้าจนไม่มีใครอยากรันก่อน merge

6 · Pyramid ไม่ได้แปลว่า “ห้ามมี E2E เยอะขึ้น”

มันแปลว่า E2E ทุกตัวต้องมีเหตุผล

บางระบบอาจมี integration เยอะเป็นพิเศษ หรือบางผลิตภัณฑ์จำเป็นต้องมี E2E หลาย browser มากกว่าปกติ แต่หลักคิดยังเหมือนเดิม:

เลือกระดับต่ำสุดที่พิสูจน์สิ่งนั้นได้
อย่าใช้ E2E ไปตรวจ logic ที่ unit test จับได้ดีกว่า
ให้แต่ละชั้นรับผิดชอบสิ่งที่มันถนัด

พูดอีกแบบคือ pyramid เป็นแนวทางการกระจายความรับผิดชอบของ test ไม่ใช่สูตรคงที่

Practice

แบบฝึก: อ่านรูปทรงของ test suite

ทีมมีชุดทดสอบดังนี้:

ทีม A: unit 20, integration 10, E2E 200
ทีม B: unit 500, integration 8, E2E 180
ทีม C: unit 420, integration 110, E2E 35

ทีม A มีแนวโน้มเป็นรูปแบบใด และจะเจอ pain อะไร

ดูคำตอบแนะนำ

ทีม A เป็นลักษณะ ice cream cone ชัดเจน เพราะ E2E มากเกินไปเมื่อเทียบกับฐาน ปัญหาหลักคือ suite ช้า เปราะ และ maintenance สูงมาก
ทีม B ทำไมยังไม่ถือว่าสมดุล แม้จะมี unit tests เยอะมาก

ดูคำตอบแนะนำ

เพราะ integration tests บางเกินไป ทำให้ช่องว่างที่จุดเชื่อมต่อยังเปิดอยู่ จึงมีลักษณะใกล้ hourglass มากกว่าพีระมิดสมบูรณ์
ทีม C มีสัดส่วนค่อนข้างดีเพราะอะไร

ดูคำตอบแนะนำ

เพราะมีฐาน unit กว้าง มี integration รองรับจุดเชื่อมต่อ และมี E2E เท่าที่จำเป็นสำหรับ flow สำคัญ ทำให้ทั้งความเร็วและความมั่นใจสมดุลกัน
ถ้า test ตัวหนึ่งเป็นแค่การตรวจ logic การคำนวณส่วนลด ควรอยู่ชั้นไหนของพีระมิด

ดูคำตอบแนะนำ

ควรอยู่ชั้น unit เป็นหลัก เพราะเป็นกฎธุรกิจที่พิสูจน์ได้จาก input/output ชัดเจน เร็วกว่าและ debug ง่ายกว่า E2E มาก

สิ่งที่ต้องเอาติดตัวไปจากบทนี้

Test Pyramid เป็นกรอบคิดเรื่องสัดส่วนของ test ในแต่ละระดับ
unit ควรเป็นฐานหลักเพราะเร็ว ถูก และเสถียรที่สุด
integration ช่วยปิดช่องว่างที่ unit test มองไม่เห็น โดยเฉพาะปัญหาที่จุดเชื่อมต่อ
E2E จำเป็นสำหรับ flow สำคัญ แต่ควรมีเท่าที่จำเป็นและมีเหตุผลชัดเจน
anti-pattern อย่าง ice cream cone และ hourglass มักทำให้ suite แพง ช้า และจับปัญหาได้ไม่คุ้มต้นทุน

← บทเรียนก่อนหน้า บทเรียนถัดไป →