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

ROI ของ Automated Tests

automation ที่คุ้มไม่ใช่ตัวที่เขียนได้เท่ที่สุด แต่คือสิ่งที่ช่วยประหยัดเวลา ลดความเสี่ยง และให้ feedback เร็วจนทีมรู้สึกได้ บทนี้จะช่วยให้คุณประเมินความคุ้มแบบจับต้องได้ ไม่ใช่ตัดสินจากความรู้สึกล้วน ๆ

เวลาเรียน: 20–24 นาที ต้องรู้มาก่อน: Lesson 03 - เกณฑ์ในการเลือก Test Cases สำหรับ Automation รูปแบบ: อ่าน + ตัวอย่างคำนวณ + mini workshop

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

ประเมินความคุ้มของ automated test แบบคิดครบทั้งต้นทุนและผลประโยชน์ได้
เข้าใจความต่างระหว่าง ROI, break-even point และ payback period
มองเห็น hidden costs ที่มักทำให้ตัวเลขดูดีเกินจริง
เปรียบเทียบ test cases หลายแบบแล้วอธิบายเหตุผลได้ว่าควรลงทุนกับอะไร
ใช้ตัวเลขช่วยคุยกับทีมและ stakeholder ได้ชัดขึ้น

1 · ทำไมเรื่องนี้ถึงสำคัญ

Automation ไม่ได้คุ้มเพราะมัน “รันเองได้” แต่คุ้มเพราะมันช่วยทีมซ้ำ ๆ ในระยะยาว

เวลาทีมคุยเรื่อง automation มักมีคำพูดประมาณนี้:

“เคสนี้เขียนได้ไม่ยาก น่าจะ automate เลย”
“ถ้า automate ได้ก็ดูโปรขึ้น”
“เดี๋ยวเขียนไว้ก่อน เผื่ออนาคตได้ใช้”

ปัญหาคือ automation ทุกตัวมีต้นทุนจริง:

เวลาออกแบบ test
เวลาเขียนและ debug script
เวลา maintain เมื่อ UI หรือ API เปลี่ยน
เวลาไล่ flaky failures

ถ้า test ตัวหนึ่งถูกใช้ซ้ำบ่อยและช่วยลด effort ได้มาก มันคือการลงทุนที่คุ้ม แต่ถ้ารันน้อยหรือเปลี่ยนบ่อย ต้นทุนอาจสูงกว่าประโยชน์

เป้าหมายของ ROI ไม่ใช่ทำให้ทุกอย่างกลายเป็นตัวเลขเป๊ะ ๆ แต่ช่วยให้ทีมตัดสินใจจากข้อมูลมากกว่าความรู้สึก

2 · ROI มองยังไงให้ง่าย

ให้คิดเป็น 2 ฝั่ง: ถ้าไม่ automate เราเสียอะไร และถ้า automate เราต้องจ่ายอะไร

ฝั่ง manual:

เวลา test ต่อครั้ง
จำนวนครั้งที่ต้องรัน
จำนวนคนที่เกี่ยวข้อง
โอกาสพลาดจากการทำซ้ำ ๆ

ฝั่ง automation:

เวลาเขียนครั้งแรก
เวลาซ่อมเมื่อระบบเปลี่ยน
เวลารันจริงต่อรอบ
เวลาที่ใช้ดูผลและ investigate failures

สูตรแบบง่าย:

ต้นทุน manual ต่อปี = เวลา manual ต่อครั้ง × จำนวนครั้งที่รันต่อปี

ต้นทุน automation ปีแรก
= เวลาออกแบบ/เขียน + เวลา debug + เวลา maintain ต่อปี + เวลารันต่อปี

มูลค่าที่ประหยัดได้ในปีแรก
= ต้นทุน manual ต่อปี - ต้นทุน automation ปีแรก

ถ้าผลลัพธ์เป็นบวกมากและคืนทุนเร็ว เคสนั้นมักน่าลงทุน

3 · Break-even Point คืออะไร

จุดที่ผลประหยัดสะสมเริ่มชนะต้นทุนตั้งต้น

คำถามที่ทีมชอบถามคือ “ต้องรันกี่ครั้งถึงจะคุ้ม”

สูตรแบบเข้าใจง่าย:

Break-even ≈ เวลาเขียน script / (เวลา manual ต่อครั้ง - เวลา automation ต่อครั้ง)

ตัวอย่าง:

เวลาเขียน script = 4 ชั่วโมง = 240 นาที
manual ต่อครั้ง = 30 นาที
automation ต่อครั้ง = 2 นาที

ดังนั้น:

240 / (30 - 2) = 8.6 ครั้ง

แปลว่าเมื่อรันประมาณ 9 ครั้ง จุดคุ้มทุนเริ่มมาถึงแล้ว ถ้ารันทุก sprint ก็คืนทุนค่อนข้างเร็ว

สิ่งที่ต้องจำคือ break-even เป็นแค่ภาพเบื้องต้น ยังไม่ได้รวม maintenance ทั้งปี ถ้า flow เปลี่ยนบ่อย ตัวเลขจริงอาจแย่ลง

4 · อย่าดูแค่ปีแรกอย่างเดียว

Test บางตัวปีแรกอาจดูแพง แต่ปีถัดไปคุ้มมาก

ให้แยกมอง 2 แบบ:

มุมมอง	ใช้ตอบคำถามอะไร
First-year ROI	ปีแรกคุ้มไหม
Steady-state ROI	หลังจากผ่านช่วง setup แล้ว มันช่วยทีมเรื่อย ๆ แค่ไหน

ตัวอย่าง:

ปีแรก: เขียน 8 ชั่วโมง + maintain 12 ชั่วโมง + รัน 4 ชั่วโมง
ปีถัดไป: ไม่ต้องเขียนใหม่แล้ว เหลือ maintain + run

บางเคสปีแรกเพิ่งพอคุ้ม แต่ปี 2 เป็นต้นไปคุ้มชัดมาก โดยเฉพาะ regression flows ที่รันทุกสัปดาห์

5 · Hidden Costs ที่มักทำให้ทีมคิดพลาด

ตัวเลขจะสวยเกินจริงทันที ถ้าคิดแค่เวลาเขียน script

Hidden Cost	ตัวอย่างในชีวิตจริง	ผลต่อ ROI
Flaky tests	fail บ้างไม่ fail บ้าง ต้อง rerun และไล่ root cause	เพิ่มเวลาทีมโดยไม่สร้างคุณค่า
Test data upkeep	account หมดอายุ, seed data ไม่ตรง	ต้องเสียเวลาซ่อมระบบรองรับ
Environment instability	staging ช้า, service ภายนอกล่ม	ทำให้ผล test ไม่น่าเชื่อถือ
Review and triage	ต้องมีคนอ่าน report และตัดสินว่า fail เพราะอะไร	เป็นต้นทุนที่มักถูกลืมใส่
Knowledge dependency	คนเขียนย้ายทีมแล้ว suite อ่านยาก	maintenance แพงขึ้นทันที

นอกจากนี้ยังมี “ต้นทุนเชิงโอกาส” คือเวลาที่ใช้เขียน test หนึ่งตัวอาจถูกเอาไป automate เคสที่สำคัญกว่าได้

6 · ตัวอย่างเทียบกันให้เห็นภาพ

เคสที่คุ้ม มักมีความถี่สูงหรือ effort manual สูงอย่างชัดเจน

กรณี A: Checkout smoke test

manual 40 นาทีต่อครั้ง
รัน 3 ครั้งต่อสัปดาห์ = 156 ครั้งต่อปี
เขียน script 8 ชั่วโมง
maintain 2 ชั่วโมงต่อเดือน = 24 ชั่วโมงต่อปี
automation run 4 นาทีต่อครั้ง = 10.4 ชั่วโมงต่อปี

คำนวณคร่าว ๆ:

manual ต่อปี = 104 ชั่วโมง
automation ปีแรก = 8 + 24 + 10.4 = 42.4 ชั่วโมง
ประหยัดปีแรก = 61.6 ชั่วโมง

นี่เป็นเคสที่คุ้ม เพราะทั้งความถี่และ business impact สูง

กรณี B: รายงานสิ้นไตรมาส

manual 20 นาทีต่อครั้ง
รัน 4 ครั้งต่อปี
เขียน script 8 ชั่วโมง
maintain 4 ชั่วโมงต่อปี
automation run รวมทั้งปี 20 นาที

คำนวณคร่าว ๆ:

manual ต่อปี = 80 นาที = 1.3 ชั่วโมง
automation ปีแรก ≈ 12.3 ชั่วโมง

แม้เขียนได้ แต่ไม่คุ้มในเชิงเวลาเลย

กรณี C: Validation matrix 150 ค่า

manual 90 นาทีต่อรอบ
รันเดือนละ 2 ครั้ง = 24 ครั้งต่อปี
เขียน script 12 ชั่วโมง
maintain 1 ชั่วโมงต่อเดือน = 12 ชั่วโมงต่อปี
automation run ต่อรอบ 5 นาที = 2 ชั่วโมงต่อปี

manual ต่อปี = 36 ชั่วโมง
automation ปีแรก = 26 ชั่วโมง

เคสนี้คุ้มไม่หวือหวาเท่า checkout แต่ก็สมเหตุสมผล โดยเฉพาะถ้าความผิดพลาดจาก manual มีผลกระทบสูง

7 · วิธีคิดเวลาคุยกับ stakeholder

อย่าพูดแค่ว่า “น่าจะคุ้ม” ให้พูดเป็นภาษาธุรกิจ

ตัวอย่างประโยคที่ใช้คุยกับทีม:

“ถ้าไม่ automate checkout ทีมจะเสียเวลาประมาณ 100 ชั่วโมงต่อปีเฉพาะ regression นี้”
“report ตัวนี้เขียนได้ แต่เพราะรันแค่รายไตรมาส ROI ติดลบชัดเจน”
“เคสนี้ไม่ประหยัดเวลาเยอะมาก แต่ช่วยลดความเสี่ยงใน flow รายได้หลัก”

เมื่อคุยแบบนี้ การตัดสินใจจะหลุดจากคำว่า “ชอบ/ไม่ชอบ automation” ไปเป็น “ลงทุนตรงไหนแล้วได้ผลจริง”

Practice

Mini workshop: คิดให้ครบก่อนตัดสินว่าคุ้ม

เคสหนึ่ง manual ใช้ 25 นาที รัน 100 ครั้งต่อปี เขียน script 6 ชั่วโมง maintain ปีละ 8 ชั่วโมง และ automation ใช้รันจริง 2 นาทีต่อครั้ง เคสนี้มีแนวโน้มคุ้มไหม

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

manual ต่อปีประมาณ 41.7 ชั่วโมง ส่วน automation ปีแรกประมาณ 6 + 8 + 3.3 = 17.3 ชั่วโมง จึงมีแนวโน้มคุ้มค่อนข้างชัด โดยเฉพาะถ้าเป็น flow สำคัญและต้องรันต่อเนื่องทุกปี
ทำไม test ที่รันปีละ 2–4 ครั้งมักไม่ค่อยคุ้มจะ automate

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

เพราะต้นทุนตั้งต้นของการเขียนและดูแล script มักสูงกว่าประโยชน์จากการประหยัดเวลา manual ต่อปีมาก ต่อให้ run time สั้นมาก ก็ยังไม่ช่วยให้คืนทุนได้เร็ว
ถ้า break-even ดูดีมาก แต่ feature เปลี่ยนทุก sprint คุณควรระวังอะไร

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

ต้องระวัง maintenance cost ที่อาจพุ่งขึ้นจนทำให้ ROI จริงแย่กว่าที่คำนวณไว้มาก สูตร break-even แบบง่ายมักไม่สะท้อนความผันผวนของระบบ
ถ้า automation ไม่ได้ประหยัดเวลาเยอะมาก แต่ลดโอกาส regression ใน payment flow คุณควรมองอย่างไร

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

ควรมองมูลค่าทางธุรกิจร่วมด้วย ไม่ใช่ดูเวลาอย่างเดียว บางเคสคุ้มเพราะช่วยป้องกันความเสียหายสูง แม้จะไม่ได้ประหยัดชั่วโมงมากที่สุด

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

ROI ของ automation ต้องคิดทั้งต้นทุนตั้งต้นและต้นทุนดูแลต่อเนื่อง
break-even point ช่วยบอกว่าต้องรันกี่ครั้งถึงเริ่มคุ้ม แต่ไม่ควรใช้แทนการมองภาพรวม
ความถี่ในการรัน, manual effort และ business impact เป็นตัวเร่งความคุ้มที่สำคัญมาก
hidden costs อย่าง flaky tests, data upkeep และ environment issues ทำให้ตัวเลขหลอกทีมได้ง่าย
การใช้ตัวเลขช่วยให้ทีมเลือก automation candidate ได้เป็นเหตุเป็นผลมากขึ้น

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