TestStar เผยเบื้องหลัง AI UI Testing ทดลองผ่าน 9 เหลือ 6 ในโปรดักชัน
ทีมพัฒนา TestStar แชร์บทเรียนการทดสอบระบบด้วย AI เผยช่องว่างระหว่างเดโมท้องถิ่นที่ผ่าน 90% กับการใช้งานจริงที่ร่วงเหลือ 60% พร้อมแนวทางแก้ปัญหา

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- TestStar เผยช่องว่าง AI UI Testing เดโมสำเร็จ 90% แต่โปรดักชันร่วงเหลือ 60%
- ทดสอบกรณีใช้งานจริง 19 ขั้นตอน พบความล้มเหลวมีสาเหตุต่างกันในแต่ละรอบ
- ระบบ Self-healing ต้องตรวจสอบผลลัพธ์ที่ตั้งใจ ไม่ใช่แค่ดูว่าการทำงานสำเร็จ
- ฮาร์เนสเลเยอร์ (Harness layer) สำคัญกว่าตัวรันคำสั่งเบราว์เซอร์
การพัฒนาแพลตฟอร์มทดสอบ UI ด้วยปัญญาประดิษฐ์อย่าง TestStar เผยให้เห็นความจริงที่ทีมพัฒนาซอฟต์แวร์ต้องเผชิญในปี 2025-2026 โดยการทดสอบในสภาพแวดล้อมจำลองแบบท้องถิ่นมักจะประสบความสำเร็จถึง 9 ใน 10 ครั้ง แต่เมื่อนำไปรันในระบบโปรดักชันขนาดใหญ่ ตัวเลขความสำเร็จกลับลดลงเหลือเพียง 6 ใน 10 ครั้ง หรือบางครั้งก็แย่กว่านั้น ซึ่งเป็นความท้าทายที่นักพัฒนาต้องทำความเข้าใจอย่างถ่องแท้
ทีมงานได้นำกรณีศึกษาจริงจากธุรกิจหนึ่งซึ่งประกอบด้วย 19 ขั้นตอน ตั้งแต่การเข้าสู่ระบบ ไปจนถึงคอนโซล SQL ป้อนคำสั่ง และการยืนยันผลลัพธ์ มาทำการทดสอบซ้ำจำนวน 8 รอบเต็ม ผลลัพธ์ที่ได้คือน้ำหนักของความล้มเหลวในแต่ละรอบนั้นเกิดจากสาเหตุที่แตกต่างกันโดยสิ้นเชิง เช่น รอบแรกเกิดจากข้อมูลที่ไม่ถูกต้อง ขณะที่รอบถัดมาเกิดจากไดรเวอร์เบราว์เซอร์ขัดข้อง ซึ่งไม่มีรูปแบบความผิดพลาดที่ตายตัวทำให้คาดเดาได้ยาก
จุดเปลี่ยนสำคัญเกิดขึ้นในรอบที่ 6 เมื่อกระบวนการทำงานย่อยเสร็จสมบูรณ์และ AI ทำงานทุกอย่างถูกต้อง แต่ผลลัพธ์กลับไม่ถูกส่งกลับไปยังฐานข้อมูล เนื่องจากความเห็นของ AI และระบบมีความขัดแย้งกัน ทีมงานต้องใช้เวลาถึงสองวันเต็มในการตรวจสอบปัญหาเชิงลึกจนพบรากเหง้าว่า ทุกขั้นตอนที่ AI กระทำนั้นไปกระตุ้นการเขียนหน่วยความจำแบบซิงโครนัส ส่งผลให้เธรดการทำงานเกิดอาการค้างและหมดเวลาไปในที่สุด

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ช่องว่างระหว่างสภาพแวดล้อมเดโมและโปรดักชันในงานทดสอบด้วย AI สะท้อนให้เห็นว่า เครื่องมือเอ็นจิ้นเบราว์เซอร์อย่าง Browser-Use หรือ Skyvern เป็นเพียงกลไกการแปลงภาษาธรรมชาติให้เป็นการกระทำ แต่สิ่งสำคัญที่ขาดไม่ได้คือฮาร์เนสเลเยอร์ (Harness layer) ซึ่งทีมพัฒนาส่วนใหญ่ต้องใช้เวลาสร้างเองเพิ่มเติมเพื่อรองรับความเสถียรในระดับองค์กร
ในระหว่างการพัฒนาโมดูลรักษาตัวเอง (Self-healing) ทีมงานพบความท้าทายใหม่เมื่อระบบเริ่มแก้ไขข้อผิดพลาดอัตโนมัติแต่กลับสร้างปัญหาเพิ่ม เนื่องจากคำว่า error ในบันทึกการทำงานทำให้ AI ตีความผิดและเข้าไปแก้ไของค์ประกอบที่ทำงานปกติอยู่แล้ว จนทำให้ชุดทดสอบพังเสียหาย แนวทางแก้ไขคือการเพิ่มชั้นกรองข้อผิดพลาดที่แท้จริง เช่น ค้นหาเฉพาะบรรทัดที่ขึ้นต้นด้วยรูปแบบการหมดเวลาหรือการยืนยันล้มเหลวเท่านั้น
- ตรวจสอบความตั้งใจของผู้ใช้จริง ไม่ใช่แค่สัญญาณความสำเร็จของระบบ
- สร้างชั้นกรองข้อผิดพลาดเพื่อป้องกันการแก้ไขที่ผิดพลาดของ AI
- ใช้คำใบ้ตำแหน่งองค์ประกอบหน้าเว็บเพื่อลดความสับสนของ AI
นอกจากนี้ ทีมงานยังได้ทดสอบกรณีการกู้คืนข้อผิดพลาด 5 กรณี โดยมีกรณีหนึ่งที่ใช้เวลาหมดเวลา 1 วินาที ซึ่งทีมงานตัดสินใจไม่ให้ AI เข้าไปช่วยขยายเวลา เนื่องจากระบบต้องการเวลาจริง 3 วินาที หากปล่อยให้ AI แก้ไขจะกลายเป็นปกปิดปัญหาการออกแบบชุดทดสอบที่แท้จริง ซึ่งการรักษาความซื่อสัตย์ของข้อมูลมีความสำคัญอย่างยิ่งต่อความเชื่อมั่นของลูกค้า
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น