การทดสอบ QA ที่ขับเคลื่อนด้วย AI บนเครื่องมือออกแบบบนเว็บรายงานว่า “All features working, pass” แต่บนแคนวาสกลับไม่แสดงผลอะไรเลย การผ่านการทดสอบที่ผิดพลาดนี้ไม่ใช่ข้อผิดพลาดในการใช้เหตุผลของโมเดล แต่เป็นผลข้างเคียงจากการที่เบราว์เซอร์จัดการกับแท็บที่ถูกซ่อนอยู่ และวิธีที่สคริปต์ทดสอบวัดค่า “ความสมบูรณ์” (health) แทนที่จะวัดผลลัพธ์ทางภาพ (visual output)

ทำไม AI QA agents ถึงอาจมองข้ามแคนวาสที่ว่างเปล่า

พวกมันรัน JavaScript, จับภาพหน้าจอ และให้โมเดลอนุมานว่าฟีเจอร์ทำงานถูกต้องหรือไม่ ในทางปฏิบัติ มีจุดบอดทางเทคนิคสองประการที่ทำให้เกิดการ "ผ่าน" ซ้ำๆ ทั้งที่ UI จริงๆ แล้วว่างเปล่า

อธิบายเรื่องการ Throttling ของแท็บที่ถูกซ่อน (Hidden-tab throttling)

Chrome MCP มักจะรันการทดสอบในแท็บเบื้องหลัง (background tabs) เพื่อให้หน้าต่างหลักว่างสำหรับงานอื่นๆ เมื่อ document.visibilityState ของแท็บอยู่ในสถานะ hidden เบราว์เซอร์จะจำกัดการทำงานของ rendering pipeline:

  • JavaScript ยังคงทำงานอยู่ จึงไม่มี runtime errors ปรากฏขึ้น
  • คอลแบ็ก (callbacks) ของ requestAnimationFrame จะหยุดทำงาน ทำให้จำนวนเฟรมแอนิเมชันค้างอยู่ที่ศูนย์
  • ตัวจับเวลา (Timers) ทำงานน้อยลงมาก เช่น การทดสอบที่คาดหวังช่วงเวลาทุกๆ 33 ms อาจตรวจพบเพียง 4 ครั้งเท่านั้น

AI agent เห็นผลลัพธ์ JS ที่สะอาดและภาพหน้าจอ จึงทึกทักเอาเองว่าแอนิเมชันทำงานแล้ว และเนื่องจากลูปการเรนเดอร์ไม่เคยสร้างพิกเซลออกมาเลย ข้อบกพร่องทางภาพจึงยังคงถูกซ่อนไว้

วิธีแก้ไขปัญหาแท็บที่ถูกซ่อน

  • รักษาแท็บที่ใช้ทดสอบให้มองเห็นได้เสมอ (visible) สำหรับการตรวจสอบแคนวาส, แอนิเมชัน หรือกราฟิกใดๆ
  • เริ่มต้นการโต้ตอบ (interactions) เฉพาะหลังจากที่แท็บอยู่ในสถานะ foreground เท่านั้น
  • ใส่การรอช่วงสั้นๆ (ไม่กี่วินาที) ก่อนที่จะจับภาพหน้าจอ เพื่อให้แน่ใจว่า frame buffer ได้รับข้อมูลแล้ว
  • หากจำเป็นต้องใช้แท็บที่ถูกซ่อน ให้เพิ่มข้อความปฏิเสธความรับผิดชอบ (disclaimer) ไว้ที่ส่วนต้นของรายงาน เช่น “rendering not visually observed”

Code health vs. feature behavior

สคริปต์ AI QA ส่วนใหญ่มักประเมิน “code health” (ความสมบูรณ์ของโค้ด): พวกมันยืนยันว่า click handlers ถูกเชื่อมต่อไว้, ไม่มี JavaScript exceptions เกิดขึ้น และไลบรารีที่จำเป็นถูกโหลดขึ้นมา สัญญาณเหล่านี้พิสูจน์ว่าโค้ดได้ทำงาน แต่ไม่ได้พิสูจน์ว่า UI เปลี่ยนแปลงตามที่ตั้งใจไว้ องค์ประกอบ canvas สามารถถูกสร้างขึ้น, เรียกใช้ routine การวาด และยังคงไม่เรนเดอร์อะไรเลยหากคำสั่งวาดภาพมุ่งเป้าไปที่ buffer ขนาดศูนย์หรือ asset ที่ว่างเปล่า

ความแตกต่างนี้สำคัญมาก เพราะเส้นทางการทำงานของโค้ดที่สมบูรณ์ (healthy code path) สามารถบดบังความผิดพลาดทางภาพที่หายไปได้

การเพิ่มการตรวจสอบพฤติกรรม (behavior checks)

  1. ระบุองค์ประกอบที่มีการเปลี่ยนแปลง (dynamic elements) – สแกนซอร์สโค้ดเพื่อหาแท็ก canvas, ฟิลด์ file-input, ปุ่มดาวน์โหลด และลูปแอนิเมชัน
  2. กำหนดผลลัพธ์ที่สังเกตได้ (observable outcomes) – สำหรับ canvas ให้กำหนดการตรวจสอบระดับพิกเซลว่า bitmap ไม่ว่างเปล่า สำหรับ file input ให้ตรวจสอบว่ามีรูปภาพตัวอย่างปรากฏขึ้น สำหรับการดาวน์โหลด ให้ยืนยันว่ามีการสร้างไฟล์ในระบบไฟล์ สำหรับแอนิเมชัน ให้ยืนยันว่าคุณสมบัติ (property) ที่ติดตามมีการเปลี่ยนแปลงเมื่อเวลาผ่านไป
  3. รายงานความครอบคลุม (Report coverage) – แนบตารางไปกับผลลัพธ์ QA โดยระบุแต่ละฟีเจอร์, สถานะ code-health และผลการตรวจสอบพฤติกรรม (behavior verification) สิ่งใดก็ตามที่ขาดการตรวจสอบพฤติกรรม ให้ระบุว่าเป็น “unverified” (ยังไม่ได้ตรวจสอบ) แทนที่จะเป็น “pass” (ผ่าน)

การใช้กฎนี้ช่วยลด false positives ในชุดการทดสอบของผู้เขียนได้อย่างมหาศาล และยังช่วยเปิดเผยความไม่สอดคล้องของ CSS ในกรณีที่ stylesheet ประกาศสีหนึ่งแต่พิกเซลที่เรนเดอร์ออกมากลับเป็นอีกสีหนึ่ง

ขั้นตอนปฏิบัติเพื่อการทดสอบทางภาพที่เชื่อถือได้

  • รันการทดสอบในแท็บที่มองเห็นได้ เมื่อใดก็ตามที่ฟีเจอร์นั้นเกี่ยวข้องกับการเรนเดอร์
  • รอให้ UI นิ่ง (settle); การหน่วงเวลาคงที่เพียงไม่กี่วินาทียมักจะเพียงพอ แต่แนวทางที่แข็งแกร่งกว่าคือการตรวจสอบ (poll) ว่า canvas ไม่ว่างเปล่าโดยใช้ getImageData
  • แยกการยืนยัน code-health ออกจากการยืนยันทางภาพ (visual assertions) ในสคริปต์ทดสอบ; ให้โมเดล AI ประเมินแต่ละส่วนแยกกัน
  • บันทึกสถานะการมองเห็น (visibility state) และตัวนับเฟรม (การเรียก requestAnimationFrame) เป็นส่วนหนึ่งของผลลัพธ์การวินิจฉัย
  • บันทึกการรันในแท็บที่ถูกซ่อนที่หลีกเลี่ยงไม่ได้ พร้อมคำเตือนที่ชัดเจน เพื่อให้ผู้ตรวจสอบในขั้นตอนถัดไปเข้าใจถึงข้อจำกัด

สิ่งที่ควรเฝ้าระวังต่อไป

เมื่อเครื่องมือ QA ที่ช่วยโดย AI แพร่หลายมากขึ้น นักพัฒนาต้องปฏิบัติกับพวกมันในฐานะ "ผู้ช่วย" ไม่ใช่ "ผู้ตัดสิน" ตัวชี้วัด code-health จะเป็นเพียงตัวแทนที่ไม่สมบูรณ์ของพฤติกรรมที่ผู้ใช้มองเห็นเสมอ บทเรียนนี้เรียบง่ายมาก: โมเดล AI สามารถรายงานได้เฉพาะสิ่งที่มันเห็นเท่านั้น หากเบราว์เซอร์ไม่เคยวาดภาพ (paint) เพราะแท็บถูกซ่อนอยู่ หรือหากสคริปต์ทดสอบไม่เคยถามว่า “มีบางอย่างปรากฏบนหน้าจอหรือไม่?” โมเดลก็จะประกาศความสำเร็จอย่างมีความสุข การเพิ่มข้อกำหนดด้านการมองเห็นและขั้นตอนการตรวจสอบพฤติกรรมจะเปลี่ยนจากผลการผ่านที่ดูสวยหรู ให้กลายเป็นผลลัพธ์ที่เชื่อถือได้