CupCode.cc
Section 03 · Module 02 · Lesson 01 · ~22–26 นาที

เกณฑ์ในการเลือก Test Cases สำหรับ Automation

พอทีมตัดสินใจจะเริ่ม automation คำถามถัดไปมักไม่ใช่ 'ทำได้ไหม' แต่คือ 'ควรเริ่มจากอะไร' บทนี้จะช่วยให้คุณเลิกเลือกเคสแบบสุ่ม แล้วหันมาใช้เกณฑ์ที่อธิบายเหตุผลกับทีมได้

เวลาเรียน: 22–26 นาที ต้องรู้มาก่อน: Module 01 - Why Automation and Why Not Everything รูปแบบ: อ่าน + criteria matrix + แบบฝึกสั้น

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

  • ใช้เกณฑ์ที่ชัดเจนในการเลือก automation candidate ได้
  • แยกปัจจัยอย่าง frequency, stability, manual effort และ business risk ออกจากกันได้
  • จัดลำดับ test cases ด้วย matrix แบบง่าย ๆ ได้
  • อธิบายกับทีมได้ว่าทำไมบางเคสควร automate ก่อนบางเคส
  • ลดการเริ่ม automation จาก “เคสที่ง่ายจะเขียน” ไปเป็น “เคสที่คุ้มจะลงทุน”
1 · ปัญหาที่เจอบ่อย

หลายทีมไม่ได้เลือกเคสที่คุ้ม แต่เลือกเคสที่หยิบง่าย

หลังจากตัดสินใจว่าจะทำ automation ทีมมักเริ่มจาก:

  • เคสที่คนในทีมคุ้น
  • เคสที่เขียนง่าย
  • เคสที่เพิ่งคุยกันอยู่พอดี

ปัญหาคือเคสที่ “ง่ายจะ automate” ไม่ได้เท่ากับเคสที่ “คุ้มจะ automate”

ผลลัพธ์ที่เจอบ่อย:

  • มี automated tests หลายตัว แต่ไม่ค่อยช่วยลด risk
  • core flow สำคัญยังไม่มี safety net
  • regression time ลดไม่มากอย่างที่หวัง

ทางแก้คือใช้เกณฑ์เดียวกันตัดสินทุกเคส

2 · เกณฑ์หลักที่ควรดู

ไม่ต้องซับซ้อน แต่ควรพอให้ตัดสินแบบมีเหตุผล

เกณฑ์ที่ใช้บ่อยมีดังนี้:

เกณฑ์ คำถามที่ควรถาม
Frequency เคสนี้รันบ่อยแค่ไหน
Stability feature หรือ flow นี้นิ่งพอหรือยัง
Manual Effort ถ้าทำด้วยมือ ยุ่งหรือใช้เวลามากแค่ไหน
Data Volume ต้องรันกับหลายข้อมูลหรือหลาย combination ไหม
Cross-browser / Platform Need ต้องเช็กหลาย browser, device หรือ OS หรือไม่
Business Risk ถ้าพลาดแล้วกระทบผู้ใช้หรือธุรกิจหนักแค่ไหน

ยิ่งเคสไหนคะแนนสูงหลายด้าน ก็ยิ่งน่าลงแรง automate ก่อน

3 · มองแต่ละเกณฑ์ให้ชัดขึ้น

จะได้ไม่ให้คะแนนจากความรู้สึกอย่างเดียว

Frequency

เคสที่รันทุกวันหรือทุก sprint มักคุ้มกว่าที่รันปีละครั้ง เพราะผลประหยัดสะสมเร็วกว่า

Stability

ถ้า flow ยังเปลี่ยนทุกสัปดาห์ script จะมีต้นทุนดูแลสูงมาก ต่อให้เคสสำคัญก็อาจยังไม่ใช่ลำดับแรก

Manual Effort

เคสที่ manual ต้องทำหลายขั้นตอน, ต้องเช็กหลายจุด, หรือมีการคำนวณเยอะ มักได้ประโยชน์จาก automation ชัด

Data Volume

ถ้าต้องทดสอบ 50–200 ชุดข้อมูล การทำด้วยมือเริ่มไม่คุ้มทันที

Business Risk

flow สำคัญอย่าง login, checkout, payment, order creation มักควรถูกพิจารณาก่อนเพราะผลกระทบสูง

4 · ตัวอย่างการใช้ criteria matrix

ไม่ต้อง perfect แค่ช่วยให้ทีมคุยกันบนฐานเดียวกัน

ตัวอย่าง matrix แบบง่าย:

เกณฑ์ Weight
Frequency 3
Stability 2
Manual Effort 2
Data Volume 2
Cross-browser Need 1
Business Risk 3

จากนั้นให้คะแนนแต่ละด้าน 1–5 แล้วคูณ weight

สิ่งสำคัญคือไม่ต้องยึดตัวเลขว่า “สูตรนี้ศักดิ์สิทธิ์” แต่ให้ใช้เพื่อทำให้เหตุผลของทีมมองเห็นได้

5 · ตัวอย่างเปรียบเทียบ

Login, Report และ Search ควรเรียงอย่างไร

ลองดู 3 เคสนี้:

เคส ภาพรวม
Login บน 3 browser รันบ่อย, feature ค่อนข้างนิ่ง, business risk สูง
Monthly Sales Report รันไม่บ่อย แต่ manual effort สูงและผลกระทบเชิงธุรกิจมี
Search 50 keywords รันบ่อย, data-driven สูง, กระทบ conversion

ถ้ามองจาก criteria matrix:

  • Search มักเด่นเรื่อง frequency + data volume
  • Login เด่นเรื่อง business risk + cross-browser
  • Report เด่นเรื่อง manual complexity แต่ frequency ต่ำ

นี่ทำให้ทีมเห็นว่าการจัดลำดับไม่ใช่เรื่องความชอบ แต่เกิดจากรูปแบบของเคส

6 · ข้อผิดพลาดที่พบบ่อยเวลาเลือก candidate

หลายทีมเลือกผิด เพราะดูแค่ด้านเดียว

1. ดูแค่ business criticality

flow สำคัญมากก็จริง แต่ถ้ามันยัง redesign ทุกสัปดาห์ อาจยังไม่ใช่ตัวแรกที่ควร automate

2. ดูแค่ว่าเขียนง่าย

สุดท้ายได้ suite ที่สวยแต่ไม่ช่วยเรื่องสำคัญ

3. ไม่ดูความถี่

เคสที่รันน้อยมากอาจไม่มีทางคืนทุนเร็วพอ

4. ไม่ดู data volume

บางเคสไม่มี business risk สูงที่สุด แต่ automation คุ้มมากเพราะ manual effort มหาศาล

7 · วิธีใช้ในชีวิตจริง

เป้าหมายไม่ใช่เลือกให้เป๊ะ แต่เลือกให้ดีพอและอธิบายได้

เวลาทีมถามว่า “จะเริ่ม automate อะไรก่อน” คุณสามารถตอบได้ดีขึ้นด้วยภาษาประมาณนี้:

  • “เราเริ่มจาก login และ search ก่อน เพราะรันบ่อยและกระทบผู้ใช้หลัก”
  • “report รายเดือนซับซ้อนมาก แต่เพราะรันไม่บ่อย จึงไว้ลำดับถัดไป”
  • “checkout สำคัญมาก แต่ flow ยังไม่ stable พอ จึงเตรียมไว้หลัง redesign เสร็จ”

นี่คือการใช้ criteria เพื่อช่วยตัดสินใจร่วมกัน ไม่ใช่เพื่อสร้างเอกสารอีกชุดเฉย ๆ

Practice

แบบฝึก: ถ้าเลือกได้ 2 เคส จะเลือกอะไร

  1. เคส A รันทุกวันแต่ business impact กลาง ๆ ส่วนเคส B รันเดือนละครั้งแต่ business impact สูงมาก คุณจะคิดอย่างไร

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

    ต้องดูหลายด้านร่วมกัน ถ้าเคส A รันถี่มากและ manual effort สูง มันอาจคุ้ม automate ก่อน แม้ impact กลาง แต่ถ้าเคส B กระทบรายได้หรือความปลอดภัยมาก อาจยังต้องถูกดันขึ้นมาก่อนเช่นกัน จุดสำคัญคืออย่าตัดสินจากปัจจัยเดียว

  2. ถ้า feature ยังเปลี่ยนทุกสัปดาห์ แต่ทุกคนยืนยันว่าเป็น critical flow คุณควรทำอย่างไร

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

    อาจยังไม่ควร automate ทั้ง flow เต็มทันที แต่เลือก automate เฉพาะส่วนที่เสถียรก่อน หรือรอจน redesign นิ่งขึ้น เพื่อเลี่ยง maintenance cost สูงเกินจำเป็น

  3. เคสหนึ่งมี data combinations 100 แบบ แต่ใช้งานจริงไม่บ่อย automation ยังมีคุณค่าไหม

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

    มีโอกาสคุ้ม เพราะ data-driven effort สูงมาก แม้ frequency ต่ำกว่าบางเคส แต่ถ้า manual ทำยากและเสี่ยงพลาด automation ก็ยังมีคุณค่า

  4. criteria matrix ควรใช้เป็นกฎตายตัวไหม

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

    ไม่ควรใช้แบบตายตัว มันเป็นเครื่องมือช่วยคิดและช่วยอธิบายเหตุผล ไม่ใช่เครื่องคิดเลขที่แทน judgment ของทีมทั้งหมด

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

  • automation candidate ที่ดีไม่ได้ถูกเลือกจากความง่าย แต่จากความคุ้มค่าและความเสี่ยง
  • frequency, stability, manual effort, data volume และ business risk เป็นเกณฑ์หลักที่ควรมองร่วมกัน
  • criteria matrix ช่วยให้ทีมคุยกันบนเหตุผลเดียวกันได้ง่ายขึ้น
  • ไม่จำเป็นต้องหาสูตรสมบูรณ์แบบ แต่ควรมีวิธีคิดที่สม่ำเสมอ
  • เคสที่ “สำคัญ” และเคสที่ “คุ้ม” บางครั้งไม่ใช่ตัวเดียวกัน ต้องชั่งน้ำหนักให้ดี
← บทเรียนก่อนหน้า บทเรียนถัดไป →