Strategy Models#

ทีมหนึ่งประกาศว่า test suite ต้องเป็น Pyramid และกำหนด 70% unit, 20% integration, 10% end-to-end โดยไม่ดู architecture ผลคือ unit tests mock ทุก dependency แต่ defect เกิดที่ database constraint และ API boundary โมเดล testing มีไว้ช่วยตั้งคำถาม ไม่ใช่สูตรจัดงบที่ใช้ได้กับทุกระบบ

ก่อนดูรูปทรง: Test มีหลายแกน#

คำว่า unit, integration, API, UI และ end-to-end มักถูกแต่ละทีมใช้ไม่เหมือนกัน ก่อนถก Pyramid หรือ Trophy ให้ระบุ test ด้วยแกนที่สังเกตได้:

Browser test อาจเป็น UI component test ที่ backend ถูก stub หรือ end-to-end journey ที่ใช้ทั้งระบบ การเรียกทั้งคู่ “UI test” แล้ววางบนยอดรูปเดียวทำให้ strategy สูญเสียรายละเอียดสำคัญ

Test Pyramid: Granularity และ Feedback Cost#

Test Pyramid ของ Mike Cohn เดิมแบ่ง Unit → Service → User Interface แนวคิดสำคัญคือใช้ tests หลาย granularity, มี small/fast tests จำนวนมากและ high-level tests น้อยลง Practical Test Pyramid ชี้ว่าชื่อ layers เดิมอาจเรียบง่ายเกินไปสำหรับ architecture สมัยใหม่ แต่ heuristic เรื่อง feedback/cost ยังมีประโยชน์

เหมาะเมื่อ:

• code มี domain logic ที่ isolate ได้มาก
• small tests ให้ feedback เร็วและ diagnosis แม่น
• high-level environment มี cost/variance สูง

ความเสี่ยงเมื่อใช้ผิด:

• ไล่จำนวนตามรูปจน mock collaboration ที่เป็น risk จริง
• unit boundary เล็กเกินและ assert implementation details
• ตีความว่า UI = E2E เสมอ
• มี small tests มากแต่ contract/database/browser gaps ยังว่าง

Pyramid ไม่ได้กำหนดเปอร์เซ็นต์สากล รูปทรงควรเป็นผลจาก test economics ของระบบ ไม่ใช่ acceptance criterion

Testing Trophy: ROI สำหรับ JavaScript/Frontend#

Kent C. Dodds อธิบาย Testing Trophy เป็น Static → Unit → Integration → End-to-End โดยให้พื้นที่ integration มากเพื่อเน้น confidence ต่อ cost ในบริบท JavaScript/frontend Static analysis/type checking ตัด error classes บางส่วน Unit เหมาะกับ isolated logic Integration ตรวจหลาย units/components ร่วมกัน และ E2E ตรวจ journey ที่มี fidelity สูงแต่แพงกว่า

เหมาะเมื่อ: frontend มี component/page interactions ที่ให้ confidence สูงโดยไม่ boot ระบบทั้งหมด และ static tools จับ type/lint errors ได้เร็ว

ความเสี่ยงเมื่อใช้ผิด: ผู้สร้างโมเดลระบุเองว่าบริบทเริ่มจาก JavaScript codebase ไม่ได้ออกแบบเป็นคำตอบของ microservices/backend ทุกแบบ คำว่า integration กว้างมาก—ต้องบอกว่า render อะไร, mock network หรือไม่ และใช้ browser/backend จริงแค่ไหน ไม่เช่นนั้นพื้นที่กว้างบน Trophy ไม่ช่วยออกแบบ suite

Test Honeycomb: Boundary-first สำหรับ Microservices#

Spotify Engineering: Testing of Microservices เสนอให้เน้น integrated tests ที่ input/output boundary ของ service ใช้ real database/process ใกล้เคียงจริง เก็บ implementation-detail tests ไว้กับ internal logic ที่ซับซ้อนโดยธรรมชาติ และมี end-to-end tests จำนวนน้อย มุมมองสำคัญคือ microservice ทั้งตัวกลายเป็น isolated component หรือ “unit” ผ่าน contract ของมัน

เหมาะเมื่อ: service มี boundary ชัด, database/queue เปิดใน test ได้เร็ว, refactor internals บ่อย และความเสี่ยงอยู่ที่ mapping, persistence, messages หรือ HTTP contracts

trade-off: integrated failure อาจ diagnosis กว้างกว่าและ setup แพงกว่า small test การเอา Honeycomb ไปใช้กับ monolith ที่ boundary ไม่ชัดหรือ dependency เปิดยากอาจสร้าง slow suite จำนวนมาก โมเดลนี้ไม่ได้แปลว่า “เลิก unit test” แต่ให้เก็บมันกับ complexity ที่ได้ประโยชน์จาก isolation จริง

Agile Testing Quadrants: Purpose และ Perspective#

Quadrants ใช้ 2 แกน—business-facing ↔ technology-facing และ support the team ↔ critique the product เพื่อทำให้ทีมเห็น testing activities ที่รูป granularity ไม่ได้บอก โมเดลเริ่มจาก Brian Marick และถูกขยายโดย Lisa Crispin/Janet Gregory; ISTQB CTFL 4.0.1 รวมไว้ใน test planning

หมายเลขไม่ได้เป็น execution order และ quadrant ไม่ใช่ role assignment Q2/Q3 ไม่ได้แปลว่า tester เท่านั้น หรือ Q1 developer เท่านั้น Whole team ต้องวางแผนทั้ง 4มุมตาม risk

Quadrants เปิดเผย blind spot ที่ automated functional suite มักพลาด: test cases อาจ support implementation ดี แต่ไม่ critique usability, operational resilience หรือ security เลย

เปรียบเทียบสิ่งที่แต่ละโมเดลตอบ#

โมเดลจึงใช้ร่วมกันได้ เช่นใช้ Quadrants หา quality gaps, Honeycomb ออกแบบ service tests, Trophy ออกแบบ frontend และเก็บ E2E journeys ตาม risk โดยไม่ต้องบังคับให้ suite ทั้งระบบเป็นรูปเดียว

Anti-pattern: Ice Cream Cone และ Hourglass#

Ice Cream Cone มี manual/UI tests มากและ small/component tests น้อย ทำ feedback ช้าและ maintenance สูง แต่การเห็นรูปนี้ไม่ได้แปลว่าต้องย้ายทุก UI assertion เป็น unit test ให้ถามว่า logic/boundary ใดควรพิสูจน์ต่ำกว่า

Hourglass มี unit และ E2E มากแต่ integration/contract ตรงกลางว่าง มักทำให้ small tests ผ่านด้วย mocks แต่ E2E fail โดย diagnosis กว้าง การเติม database/API/component contract tests อาจให้ evidence คุ้มกว่าเพิ่มปลายทั้ง 2

ชื่อรูปเป็น diagnostic shorthand ไม่ใช่ verdict ระบบบางชนิดอาจมี shape แปลกเพราะ risk/context จริง

วิธีเลือก Strategy Model#

1. วาด architecture และ ownership boundaries
2. ลิสต์ product risks กับ quality characteristics
3. วัด feedback time, failure localization, setup/maintenance cost และ fidelity ของ test seams
4. ใช้ Quadrants หา perspective ที่ขาด
5. ใช้ Pyramid/Trophy/Honeycomb เป็น hypothesis ว่าควรลงทุนตรงไหน
6. ทดลอง tracer tests แล้วเก็บ duration, flaky rate, defect yield และ maintenance evidence
7. ปรับ portfolio จากข้อมูล ไม่ปกป้องรูปทรงเดิม

Workshop Hub: Strategy แบบผสม#

Static: types, lint, OpenAPI/schema checks
Small: capacity/cutoff pure rules
Service boundary: reservation API + real database constraints
Frontend integration: form/dialog/error mapping with controlled network
Browser E2E: reserve/cancel critical journeys with real services
Critique: exploratory usability, accessibility, load, security and recovery exercises

รายการนี้ยังไม่ใช่ test plan จนกว่าจะผูกแต่ละบรรทัดกับ risk, owner, environment, oracle และ exit criteria

Lab: Defend Your Shape#

สร้าง strategy 2 แบบสำหรับ Workshop Hub:

• แบบ A: modular monolith ที่ database เปิดใน integration tests ได้เร็ว
• แบบ B: frontend เรียก 5 remote services ที่ทีมควบคุมไม่ได้

ระบุต่อแบบว่าใช้โมเดลใดเป็น lens, จุดลงทุนหลัก, mock/real boundaries, fastest feedback loop, critical E2E, Q3/Q4 activities และ evidence ที่จะใช้ปรับ strategy หลัง 1 เดือน ห้ามตอบด้วยเปอร์เซ็นต์อย่างเดียว

รายการตรวจสอบ#

• ทีมตกลงความหมาย unit/integration/E2E จาก observable boundary
• Model ถูกใช้เป็น heuristic ไม่ใช่ quota
• Architecture และ ownership เป็น input ของ test shape
• Quadrants เปิดเผย business/technology และ guide/critique gaps
• Real vs mocked dependencies ระบุทุก test seam สำคัญ
• Strategy ปรับจาก duration, failures, incidents และ maintenance evidence

อ่านเพิ่มเติม#

• The Practical Test Pyramid
• Testing Trophy for frontend applications
• Testing of Microservices
• ISTQB CTFL: test pyramid and testing quadrants