Risk-Based Automation Strategy#

ทีม Workshop Hub เคยมี browser test 180 รายการ แต่ release ยังพังเมื่อ capacity ถูกจองเกิน เพราะ tests ส่วนใหญ่เปิดหน้าเดียวกัน คลิกทุกอย่างผ่าน UI และตรวจเพียงว่ามี toast สีเขียว จำนวน test จึงไม่เท่ากับ confidence: ถ้า seam ที่ทดสอบไม่ตรง failure mode หลักฐานที่ได้ก็ไม่ตอบคำถาม

หลังจากแยก testing objectives และข้อจำกัด, เปรียบเทียบ strategy models และสร้าง conditions ด้วย test design techniques แล้ว บทนี้จะเปลี่ยน theory เหล่านั้นเป็น automation portfolio และตัดสินว่า evidence ส่วนใดควรมาจาก browser/API tool

เริ่มจาก Risk ไม่ใช่รายการหน้า#

ถามก่อนว่า “ถ้าพฤติกรรมนี้ผิด ใครเสียอะไร และเราต้องเห็นหลักฐานที่ boundary ไหน” สำหรับ Workshop Hub:

การทดสอบที่ seam ต่ำกว่ามักเร็วและระบุสาเหตุได้ดีกว่า แต่ไม่ได้พิสูจน์ว่า browser, routing และ deployed configuration ทำงานร่วมกัน จึงใช้หลายชั้นโดยให้แต่ละชั้นมี claim ชัด ไม่ใช่ทำ journey เดียวซ้ำทุกชั้น

Playwright ควรรับผิดชอบอะไร#

Playwright Test เหมาะกับ browser end-to-end, component boundary บางกรณี และ HTTP API tests ที่ต้องใช้ runner, fixtures, projects, parallelism กับ reports ร่วมกัน แต่ไม่ควรแทน pure unit test หรือ database concurrency test ที่ต้องควบคุม transaction โดยตรง

Playwright browser test ที่คุ้มค่ามักอยู่ใน 3 กลุ่ม:

1. Critical journey — ผู้ใช้ค้นหา workshop, จอง และเห็นรายการของตน
2. Browser contract — form validation, focus, dialog, download, redirect และ responsive behavior
3. Boundary integration — frontend ส่ง request ถูกและแสดง success/error จาก backend ตาม contract

ถ้า logic คำนวณ waitlist position เป็น pure function ให้ทดสอบระดับ unit ถ้า claim คือ unique constraint ให้ทดสอบกับ database จริง การลากทุกอย่างผ่าน browser ทำให้ feedback ช้าและ failure มีสาเหตุได้หลายชั้น

เขียน Behavior Inventory#

แทนที่จะลิสต์ว่า “ทดสอบหน้า Workshops” ให้เขียน behavior statement ที่อ่านเป็น specification:

BOOK-RESERVE-001 - reserves the last available seat for an authenticated learner
BOOK-RESERVE-002 - joins the waitlist when no seat remains
BOOK-RESERVE-003 - rejects a duplicate reservation without creating another seat claim
AUTH-ADMIN-001 - hides organizer controls from learners
AUTH-ADMIN-002 - rejects a learner calling the organizer API directly

1 test ควรมีเหตุผลหลักที่ทำให้ fail 1 เรื่อง Mega-test แบบ create → edit → publish → reserve → cancel → export ทำให้ failure แรกบัง behavior หลังทั้งหมด แยก tests เมื่อแต่ละ behavior มี setup อิสระได้ เก็บ flow ยาวไว้เฉพาะกรณีที่ “การเดินทางต่อเนื่องทั้ง flow” คือสิ่งที่ต้องพิสูจน์จริง

จัดลำดับด้วย Cost of Failure#

ใช้ตารางสั้น ๆ ต่อ feature:

Behavior: Reserve an available seat
Failure impact: learner cannot attend; support load increases
Likelihood: medium
Required evidence: API persists one reservation; browser shows confirmed state
Fastest useful seam: API integration
Browser coverage: one happy path plus visible full/waitlist errors
Owner: Learning Platform team

เริ่ม automation จาก high-impact/high-likelihood behavior แล้วเติม boundaries เช่น zero capacity, last seat, duplicate click, missing session และ wrong role ไม่จำเป็นต้อง automate ทุก permutation ผ่านทุก browser Projects ควรสะท้อน browser/device ที่ผลิตภัณฑ์รองรับและข้อมูลการใช้งานจริง ไม่ใช่สร้าง matrix เพื่อให้ dashboard ดูใหญ่

Test Oracle ต้องตรวจ Result#

หลังคลิก Reserve อย่าพิสูจน์เพียงว่า request ถูกส่งหรือ spinner หาย ให้ assert result ที่ contract สัญญา:

• heading ของ confirmation แสดงชื่อ workshop ที่เลือก
• seat state เป็น Reserved สำหรับ learner คนนี้
• refresh แล้วยังเห็น reservation เดิม
• API inquiry คืน resource เดียว ไม่ใช่ 2 รายการจาก double submit

แต่ละ assertion เพิ่ม claim และค่า maintenance ให้เลือกเท่าที่จำเป็น หาก API test พิสูจน์ persistence แล้ว browser test อาจตรวจเพียง visible outcome กับ navigation ไม่ต้อง parse database ผ่าน UI อีกครั้ง

หลีกเลี่ยง Coverage Theater#

สัญญาณว่า suite กำลังวัด activity แทน confidence ได้แก่:

• เป้าหมายเป็นจำนวน test cases หรือ line coverage โดยไม่ผูกกับ risk
• ทุก endpoint มีแค่ status success แต่ error contract และ authorization ว่าง
• retries ทำให้ build เขียวแต่ไม่มี owner วิเคราะห์ first-attempt failure
• skip/fixme ไม่มีเหตุผล issue owner หรือ expiry
• test ใช้ production-like data ร่วมกันจนต้องรัน serial ทั้งหมด
• UI tests assert implementation detail เช่น CSS class หรือ DOM nesting

Playwright แนะนำให้ทดสอบ user-visible behavior, ทำ tests ให้ isolated และใช้ locators ที่ผู้ใช้รับรู้ หลักเหล่านี้ช่วยลด coupling แต่ทีมยังต้องกำหนด risk และ oracle เอง

Lab: Workshop Risk Map#

เลือก feature “Cancel reservation” แล้วเขียนอย่างน้อย 6 behaviors ครอบคลุม happy path, already cancelled, cutoff time, wrong user, organizer override และ reminder failure จากนั้นระบุต่อ behavior ว่า:

1. test seam ใดเร็วที่สุดที่พิสูจน์ claim ได้
2. dependency ใดต้องเป็น real, fake หรือ controlled response
3. data ใครสร้างและลบ
4. artifact ใดช่วย debug เมื่อ fail
5. browser test เพิ่มหลักฐานอะไรที่ API test ไม่มี

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

• ทุก test เชื่อมกับ observable behavior หรือ risk
• เลือก seam ต่ำที่สุดที่ยังพิสูจน์ claim ได้
• Critical journeys สั้นและมี oracle ที่ตรวจผลลัพธ์จริง
• Authorization มีทั้ง UI affordance และ server-side rejection evidence
• Browser/device matrix มาจาก support policy หรือ usage evidence
• Skip, retry และ known gap มี owner กับเงื่อนไขปิด

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

• Playwright best practices
• Playwright test isolation
• Playwright API testing