อะไรที่ไม่ควร Automate
หนึ่งในสาเหตุที่ automation ล้มเหลวไม่ใช่เพราะทีมเขียน test ไม่เก่ง แต่เพราะเลือกสิ่งที่ไม่เหมาะจะ automate ตั้งแต่แรก บทนี้จะช่วยให้คุณมองเห็นต้นทุนแฝงและตัดสินใจได้ว่าอะไรควรปล่อยให้คนทำต่อไป
จบบทนี้แล้วคุณจะ...
- ระบุงานทดสอบที่มักไม่คุ้มกับการ automate ได้ชัดขึ้น
- เข้าใจว่าการ automate ทุกอย่างเป็น anti-pattern อย่างไร
- มอง maintenance cost เป็นส่วนหนึ่งของการตัดสินใจตั้งแต่ต้น
- ใช้คำถามง่าย ๆ เพื่อประเมินว่าเคสไหนยังไม่ควรลงแรงเขียน script
- กล้าบอกทีมได้อย่างมีเหตุผลว่า “เคสนี้ manual ยังเหมาะกว่า”
พังไม่ได้พังเพราะเขียน script ไม่เป็น แต่เพราะเลือกผิดเรื่อง
หลายทีมเริ่ม automation แบบไฟแรง:
- รวบรวม manual test cases ทั้งหมด
- ตั้งเป้าว่าจะ automate ให้ได้เยอะที่สุด
- ใช้จำนวนสคริปต์เป็นตัววัดความสำเร็จ
ช่วงแรกทุกอย่างดูดี แต่ไม่นานจะเริ่มเจอ:
- test fail จำนวนมากจากสาเหตุเดิม ๆ
- locator พังเพราะ UI ขยับนิดเดียว
- test data หมดอายุ
- ต้องใช้เวลามากกับการซ่อม test มากกว่าการหาบั๊ก
นี่ทำให้เห็นว่าคำถามที่สำคัญไม่ใช่ “automate ได้ไหม” แต่คือ “คุ้มไหม และเหมาะไหม”
เพราะเครื่องมือไม่ได้เก่งที่สุดในทุกงาน
Exploratory Testing
exploratory testing ต้องใช้:
- การตั้งสมมติฐาน
- การลองหลายทางตามสิ่งที่เจอ
- การสังเกตสิ่งผิดปกติที่ไม่ได้อยู่ในสคริปต์
สิ่งเหล่านี้เป็นจุดแข็งของมนุษย์ ไม่ใช่ของ automation
One-time / Rarely-run Tests
ถ้าทดสอบปีละครั้งหรือรันครั้งเดียว เช่น migration เฉพาะกิจ บ่อยครั้งเวลาที่ใช้เขียนและ debug script จะมากกว่าทำด้วยมือ
UI ที่ยังเปลี่ยนเร็ว
ถ้าหน้าจอยัง redesign ทุกสัปดาห์ การเขียน UI automation ตอนนี้มักกลายเป็นหนี้ทันที เพราะ script จะต้องตามแก้ตลอด
Low-risk, Low-value Areas
หน้า static content หรือฟังก์ชันที่กระทบธุรกิจต่ำมาก อาจไม่คุ้ม effort เมื่อเทียบกับสิ่งสำคัญกว่า
Usability / UX Judgement
คำถามอย่าง:
- ปุ่มนี้ชัดไหม
- flow นี้งงไหม
- ผู้ใช้ลังเลตรงไหน
เป็นคำถามที่ต้องใช้คนจริงตัดสิน
ค่าใช้จ่ายของ automation ไม่ได้จบตอน “เขียนเสร็จ”
ต้นทุนที่มักเกิดตามมา:
| ต้นทุน | ตัวอย่าง |
|---|---|
| Maintenance | locator เปลี่ยน, flow เปลี่ยน, config เปลี่ยน |
| Flaky Investigation | test fail บ้างไม่ fail บ้าง ต้องมานั่งไล่ |
| Test Data Upkeep | account หมดอายุ, data สกปรก, state ไม่คงที่ |
| Environment Dependency | test env ช้า, service ภายนอกไม่เสถียร |
| Knowledge Dependency | คนที่เขียนออกจากทีม ไม่มีคนดูแลต่อ |
ถ้าคุณไม่คิดต้นทุนเหล่านี้ตั้งแต่ต้น การ automate บางเคสจะดูคุ้มเกินจริง
ถาม 5 ข้อนี้ก่อนทุกครั้ง
- เคสนี้รันบ่อยพอไหม
- สิ่งที่เราจะตรวจสามารถตัดสินแบบ objective ได้ไหม
- feature นี้นิ่งพอหรือยัง
- ถ้า fail แล้วคุณค่าทางธุรกิจสูงพอไหม
- ทีมพร้อมดูแลมันระยะยาวหรือไม่
ถ้าคำตอบหลายข้อยังเป็น “ไม่” หรือ “ยังไม่แน่” manual test อาจยังเหมาะกว่าในตอนนี้
บางเคสแค่ยังไม่ถึงเวลา
ตัวอย่าง:
- วันนี้ยังไม่ควร automate เพราะ UI กำลัง redesign
- เดือนหน้าหลัง flow นิ่งแล้ว ค่อยกลับมาพิจารณาใหม่
นี่คือ mindset สำคัญ เพราะหลายเคสไม่ได้ “ห้าม automate” ตลอดไป แค่ยังไม่ถึง timing ที่คุ้ม
ใช้สายตาแบบ cost-vs-value ช่วยตัดสิน
| เคส | แนวโน้ม |
|---|---|
| Smoke checkout หลัง deploy ทุกวัน | ควร automate |
| exploratory feature ใหม่ที่ยังไม่มี requirement ชัด | ยังไม่ควร automate |
| data validation 300 ชุดค่าที่ต้องเทียบผลแน่นอน | ควร automate |
| หน้า FAQ ที่ content เปลี่ยนเรื่อย ๆ และ business impact ต่ำ | มักไม่คุ้ม |
| visual polish เรื่อง spacing/fine alignment | มักยังต้องใช้คนตัดสิน |
หลายทีมพังเพราะคิดว่า automate มาก = ดีมาก
1. เอา manual test cases ทั้งหมดมาแปลงเป็น UI scripts ตรง ๆ
สิ่งที่ได้คือ suite ใหญ่ เปราะ และช้า
2. รีบ automate ของที่ยังไม่ stable
ทำให้ maintenance cost พุ่งเร็วมาก
3. วัดความสำเร็จจากจำนวน test scripts
แทนที่จะวัดจาก regression time, confidence หรือ escaped defects
4. ไม่คิดว่าใครจะดูแลต่อ
suite ดีแค่ไหนก็เสื่อมเร็ว ถ้าไม่มี ownership ชัด
แบบฝึก: ควร automate ตอนนี้ไหม
flow สมัครสมาชิกกำลังจะ redesign ในอีก 2 สัปดาห์ แต่ทีมอยาก automate ตอนนี้เลย คุณจะตอบอย่างไร
ดูคำตอบแนะนำ
มักยังไม่คุ้ม เพราะ script ที่เขียนตอนนี้มีโอกาสสูงที่จะต้องแก้หรือทิ้งเร็วมาก ถ้าจะลงทุน ควรรอให้ flow นิ่งกว่านี้ก่อน หรือ automate แค่ส่วนที่เสถียรจริง
QA ต้องตรวจสอบผลคำนวณภาษี 200 ชุดข้อมูลซ้ำทุก release งานนี้เหมาะกับ automation ไหม
ดูคำตอบแนะนำ
เหมาะมาก เพราะเป็นงานซ้ำ, ตรวจแบบ objective ได้, และ data-driven เป็นจุดแข็งของ automation
ทีมอยาก automate usability test ของหน้า onboarding เพื่อวัดว่าผู้ใช้สับสนไหม คุณคิดเห็นอย่างไร
ดูคำตอบแนะนำ
automation ช่วยเช็กพฤติกรรมเชิงกลไกได้ แต่การวัดความสับสนหรือความเข้าใจของผู้ใช้ยังต้องใช้มนุษย์เป็นหลัก
ถ้าเคสหนึ่ง business impact ต่ำมาก แต่ automate ง่ายมาก ควรทำไหม
ดูคำตอบแนะนำ
ไม่จำเป็นเสมอไป เพราะ “ง่าย” ไม่ได้แปลว่า “คุ้ม” คุณยังต้องดูโอกาสรันซ้ำ, คุณค่าที่ได้, และงานสำคัญกว่าที่ยังรออยู่
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- การ automate ทุกอย่างเป็น anti-pattern ที่มักพาทีมไปสู่ maintenance cost สูงเกินจำเป็น
- งานที่ใช้ judgment ของมนุษย์สูง เช่น exploratory หรือ usability มักยังไม่เหมาะกับ automation
- คำว่า “ยังไม่ควร automate” มักหมายถึง timing ยังไม่เหมาะ ไม่ได้แปลว่าห้ามตลอดไป
- ต้นทุนของ automation ต้องรวม maintenance, flaky investigation และ environment overhead ด้วย
- การรู้ว่าอะไร “ไม่ควร” automate สำคัญพอ ๆ กับการรู้ว่าอะไร “ควร” automate