ทำไม Automation ที่สร้างกันมาแทบตาย สุดท้ายก็ไม่ได้ใช้จริงทุกที

เคยเป็นกันมั้ยคะ
ตัดสินใจลงทุนทำ Automation Testing กันจริงจัง
ใช้เวลาหลายสัปดาห์ เขียน Script แปลง Test Case ที่มีอยู่เป็น Automation
แล้วก็เอาไปให้ทุกคนใช้ ทีมก็ภูมิใจกับของที่ทำไป ทุกคนตื่นเต้นที่จะได้ใช้อะไรใหม่ๆ

6 เดือนผ่านไป…

🤖💥 Script เริ่มพังไปทีละตัว
เราก็เข้าไปแก้ตรงจุดที่พัง แล้วก็ใช้ต่อ
ผ่านไปซักพัก เอ๊า ทำไมพังอีกแล้ว ก็แก้อีก
ผ่านไปอีกซักพัก มีฟีเจอร์ใหม่ออกมา เอ๊า Test ที่มีอยู่พังหมดเลย

สุดท้ายก็ไม่มีใครสนใจผลเทสของเราอีก
ไม่มีใครไปกดรัน เพราะรู้ว่าเดี๋ยวมันก็แดง
งานก็เร่ง ต้องออกตาม timeline ที่เลื่อนแล้วเลื่อนอีก
สุดท้ายทุกคนก็กลับไปรัน Manual เหมือนเดิม เพราะไม่มีเวลามาดู

แค่ทำงานใน Sprint ก็หัวหมุนแล้ว

คิดว่าปัญหาเกิดจากอะไรคะ
มีใครไม่เก่งรึเปล่า?
หรือเราเลือก Tool ผิด?
หรือเรายังตั้งใจทำงานกันไม่พอ?

ไม่ใช่ซักอย่างเลยนะคะ แต่จริงๆ แล้วมันเกิดจากสิ่งเหล่านี้ค่ะ

เคยเห็น Automation Test แบบนี้มั้ยคะ หนึ่งข้อทำมันทุกอย่าง

เปิดหน้า Login -> กรอก Email -> กรอก Password -> กด Submit -> ไปหน้า Dashboard -> กดเพิ่มสินค้าลงตะกร้า -> กด Checkout -> ตรวจ Order Summary -> …

ก็เหมือนจะเป็น Flow ที่ดูสมเหตุสมผลใช่มั้ยคะ User ก็ทำแบบนี้ทั้งนั้น
แต่พอมันพังขึ้นมา ทีนี้ล่ะ งานงอก เพราะเวลามันพัง มันก็บอกแค่ว่า Test นี้พัง
แต่เราจะไม่รู้เลยว่ามันพังตรงไหนแน่ ต้องเสียเวลาเข้าไป Investigate อีก

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

อย่างเช่น ถ้าหน้า Dashboard พัง
กลายเป็นว่า เราจะเทส Checkout และ Order Summary ไม่ได้ตามไปด้วย
ทีนี้ถ้ามีบั๊กตรง Checkout ขึ้นมา กว่าจะเจอ ก็ต้องรอแก้ Dashboard แล้วรันใหม่อีกรอบ
หรือรอคนเข้าไปเทส Manual เอง แทนที่จะเจอตั้งแต่การเทสรอบแรก

ถ้าเป็น Manual ที่ใช้คนเทส เรายังดูเอาหน้างาน แล้วอาจจะมีท่า Workaround ที่หลบบั๊กแล้วไปเทสตรงจุดอื่นได้
แต่ถ้าเป็น Script เทส มันไม่รู้นะคะว่าควรจะต้องทำยังไง นอกจากเราจะบอกมัน พอมันเฟล มันก็แค่หยุดทำงาน แล้วก็ไม่ได้ทำอะไรต่อ

❌ Average QA: เขียน Script ตาม Flow ของ User ยาวๆ เพราะมันดู “สมจริง”

✅ QA ร่างทอง: แยก Test ออกเป็นชิ้นเล็กๆ ที่ไม่มี Dependency ต่อกัน แต่ละ Test มีหน้าที่ชัดเจน พังที่ไหนรู้ทันที (เอาไว้เราจะมาพูดกันเรื่อง Atomic Test Cases ในโพสต่อๆไปนะคะ)

อันนี้เนี่ย เป็นปัญหาที่เจอบ่อยมากกกกกกกกกกเลยค่ะ
ก็เวลาเราเขียน Test Case เรายังมีช่อง Test Data ไว้ให้กรอกเลยนี่นา
Automation Test ก็น่าจะเหมือนกันจริงมั้ยคะ

แล้วเราก็จะเห็นอะไรแบบนี้เต็มไปหมด

login("testuser@company.com", "Password123") 
addToCart("iPhone 15 Pro", 1) 
applyDiscount("SAVE10")

คำถามคือ… ถ้าเราเปลี่ยน Test Environment, User โดนลบ, Discount code หมดอายุ
Script พังหมดเลย… โดยที่ตัวแอพไม่ได้มีปัญหาอะไรด้วยซ้ำ

❌ Average QA: เข้าไปเปลี่ยน Data ให้ตรง พังอีกก็แก้อีก วนไป

✅ QA ร่างทอง: แยกการจัดการ Test Data ออกมาเลย หรือ ใช้ Test Data แบบ Dynamic ทำให้เราควบคุมได้ ไม่ติดอยู่กับ Script

ถ้าเป็นโค้ดฝั่งของ Product ที่เราจะเอาขึ้น Production ถ้ามีบั๊ก เราก็ต้องแก้ถูกมั้ยคะ
ไม่มีใครบอกว่าเอาไว้ก่อนก็ได้ ไม่เป็นไร
รวมไปถึง เรามีการทำ Code Review กันทุกครั้ง มีการบังคับใช้ Coding Standard ต่างๆ
ถ้าผิด ก็ต้องแก้ให้ตรงกับ Format ที่ตกลงกันไว้

แต่พอเป็น Automation Test Script ทำไมพอมันพัง เราก็เอาแต่กด Retry อยู่อย่างนั้น
พอรอบสองมันผ่านก็โอเค ถือว่าเทสผ่าน ไม่ได้มีการกลับมาดูว่าเกิดขึ้นเพราะอะไร หรือมีโค้ดตรงจุดไหนที่ออกแบบมาไม่ดี

ความคิดนี้แหละค่ะ ที่จะทำให้ Automation ค่อยๆ ตายไปทีละนิด

✅ QA ร่างทอง ต้องมอง Automation Script เป็น Production Code ด้วยเหมือนกัน

📌 พังแล้วต้องรีบแก้ ไม่ใช่กด Retry แล้วสวดมนต์ให้มันผ่านก็พอ
📌 ทำ Code Review ทุกครั้ง มี Standard ที่ชัดเจน ไม่ใช่ใครอยากเขียนแบบไหนก็เขียน
📌 มี Owner ชัดเจน ใครจะดูแลส่วนไหน ถ้าพังใครจะเป็นคนมาแก้ ไม่ใช่เขียนไปแล้วก็จบ

ถ้าทำได้แบบนี้ จะเป็นการอัพเกรด Automation Test ของเราให้เป็นร่างทองไปด้วยค่ะ

บางทีเราก็ทำ Automation Test เพราะโดนสั่งมาว่า ต้องมี Automation Test Coverage 80% นะ
ก็เลยเขียนขึ้นมาให้มันครบๆ ตัวเลข Coverage สุง แต่ลืมดูว่าเทสนี้มีไว้เพื่ออะไร

ไม่มีใครตอบได้ว่า Objective ของ Test Case ข้อนี้คืออะไร
ถ้าพังแล้ว จะกระทบส่วนไหนบ้าง
Test Case นี้ มีไว้ป้องกันความเสี่ยงตรงจุดไหน

❌ Average QA: มี Test Case ที่ Coverage แน่นมาก ครบทุก Requirement แต่เวลามีบั๊ก ก็จับไม่ได้อยู่ดี

✅ QA ร่างทอง: ถามก่อนเสมอว่า Test Case นี้มีไว้เพื่ออะไร ถ้าพังหมายถึงอะไร กระทบ Business ยังไง ถ้ามีบั๊กแล้วข้อนี้จะจับได้จริงมั้ย

แล้วเราก็จะได้ Automation Test ที่ตอบโจทย์ Business จริงๆ ค่ะ

💡 กลับมาที่คำถามว่า “แล้ว AI ช่วยได้มั้ย”

ถ้าเราสังเกตดูให้ดี ทุกอย่างก็กลับมาที่จุดเดิมอีกแล้วนะคะ
ถ้าเรารู้ว่า Automation Test ที่ดี หน้าตาเป็นยังไง Structure ต้องเป็นยังไง ต้องตรวจอะไรบ้าง
เราก็จะสามารถใช้ AI ช่วยทำ Automation Test ที่ดี ได้เร็วขึ้นกว่าเดิมมาก

แต่กลับกัน
ถ้าเราไม่รู้ว่า Automation Test ที่ดีเป็นยังไง
ถึง AI จะช่วยสร้าง Script ให้เราได้ เราก็อาจจะได้ Script ที่จะพังในอีก 6 เดือนต่อมานั่นเองค่ะ
Garbage In, Garbage Out ยังเป็นคำที่ใช้ได้อยู่เสมอ

เขียน Automation Test ได้ กับ เขียน Automation Test ที่ทีมเชื่อถือ และมีคุณค่าต่อทีมอย่างแท้จริง มันต่างกันคนละเรื่องเลยค่ะ