[Action] Copilot browser tools QA checklist Deep Dive

Copilot เปิดเบราว์เซอร์ให้ Agent แล้ว: ทีมเล็กต้องเช็กอะไรก่อนให้ AI ทดสอบเว็บจริง

ข่าวนี้ฟังเหมือนฟีเจอร์ dev tool ธรรมดา แต่สำหรับคนทำระบบจริง มันคือเส้นแบ่งใหม่ของ AI agent

ก่อนหน้านี้ agent ส่วนใหญ่ช่วยเราในพื้นที่ปลอดภัยกว่า เช่น อ่านไฟล์ แก้โค้ด รัน test หรือสรุป log

แต่เมื่อ agent เปิด browser จริงได้ มันเข้าใกล้งานที่เคยต้องใช้คนมากขึ้น เช่น กด flow สมัครสมาชิก เช็กหน้า checkout ดู console error จับ screenshot หรือเทสต์หน้า landing page หลัง deploy

ประโยชน์ชัดมาก

แต่ความเสี่ยงก็ชัดเหมือนกัน

เพราะ browser ไม่ใช่แค่หน้าจอ มันมี cookie, session, clipboard, permission, domain, form, payment page, admin panel และข้อมูลจริงซ่อนอยู่

1) เกิดอะไรขึ้น

GitHub ประกาศว่า Browser tools for GitHub Copilot in VS Code เป็น generally available แล้ว

ในประกาศ GitHub บอกว่า browser tools เปิด by default หลัง GA และ agent สามารถขับ browser จริงได้ เช่น เปิดหน้าเว็บ navigate, click, type, hover, drag, handle dialogs, อ่าน page content, เก็บ console errors และ take screenshots

ภาษาคนทำงานคือ Copilot agent ไม่ได้อยู่แค่ในไฟล์แล้ว

มันเริ่มเข้าไปอยู่ในวงจร QA ของเว็บแอปได้

เช่นเราสั่งว่า:

“เปิดหน้า pricing แล้วลอง flow สมัครสมาชิก ดูว่ามี console error ไหม เก็บ screenshot ของ step ที่ fail ให้หน่อย”

หรือ:

“หลังแก้ CSS แล้วเปิดหน้า mobile preview เช็กว่า CTA ไม่ทับ widget และ screenshot หลักฐานให้ดู”

นี่คือจุดที่ agent เริ่มเป็นผู้ช่วย QA เบื้องต้น ไม่ใช่แค่ผู้ช่วยเขียนโค้ด

2) ทำไมมันสำคัญกว่าที่เห็น

สิ่งที่น่าสนใจที่สุดในประกาศนี้ไม่ใช่แค่ agent คลิกเว็บได้

แต่คือ GitHub พูดถึง boundary หลายชั้นพร้อมกัน

หนึ่ง user tabs เป็น private by default

Agent อ่านหรือแตะหน้าเว็บที่เราเปิดเองไม่ได้ จนกว่าเราจะเลือก Share with Agent และเราถอน access ได้

สอง agent tabs ถูกแยก session

หน้าเว็บที่ agent เปิดเองใช้ fresh sessions ไม่มี access ไปยัง cookies หรือ storage จาก browser ปกติของเรา และ agent ที่รันพร้อมกันใน Agents window ก็แยก browser tabs ของตัวเอง

สาม sensitive permissions ต้องขออนุมัติ

กล้อง ไมโครโฟน location notifications และ clipboard reads ไม่ถูกให้โดยอัตโนมัติ ต้องมี explicit approval และ agent อนุมัติแทนเราไม่ได้

สี่ admin มี policy controls

GitHub ระบุทั้ง dedicated on/off switch workbench.browser.enableChatTools และ network domain controls อย่าง chat.agent.allowedNetworkDomains, chat.agent.deniedNetworkDomains และ chat.agent.networkFilter

แปลว่าเรื่องนี้ไม่ควรถูกมองเป็นแค่ฟีเจอร์ของ developer คนเดียว

มันคือการออกแบบวิธีให้ agent เข้าถึงเว็บจริงอย่างมีขอบเขต

3) Operator Lesson: อย่าเริ่มจาก “ให้ AI ลองกดเว็บให้หน่อย”

หลายทีมจะเริ่มใช้ฟีเจอร์แบบนี้ด้วยคำสั่งง่าย ๆ

“ลองเปิดหน้าเว็บแล้วเช็กให้หน่อย”

คำสั่งนี้เร็ว แต่หลวมเกินไป

ถ้าเป็นเว็บ demo ที่ไม่มี login ไม่มีข้อมูลจริง ก็ไม่เป็นไร

แต่ถ้าเป็นเว็บ production, admin, checkout, CRM, ad manager, analytics dashboard หรือหน้า campaign ที่ต่อกับ pixel จริง คำสั่งเดียวกันอาจกลายเป็นปัญหา

วิธีคิดที่ดีกว่าคือแบ่ง browser-agent work ออกเป็น 4 ชั้น

ชั้นแรก: page scope

Agent เปิดเว็บไหนได้ เว็บไหนห้ามเปิด และ environment ไหนใช้ได้ เช่น local, staging, preview, production read-only

ชั้นสอง: session scope

Agent ใช้ session ว่าง, test account, staging account หรือ user session ที่เรา share ให้ชั่วคราว

ชั้นสาม: action scope

Agent ทำอะไรได้ เช่น navigate, click, type dummy data, inspect console, screenshot แต่ห้าม submit payment, send email, delete record, change setting หรือ publish

ชั้นสี่: proof scope

Agent ต้องส่งหลักฐานอะไรกลับมา เช่น URL, viewport, console error, screenshot, step ที่ทำ, expected vs actual, และสิ่งที่ยังไม่ได้ทดสอบ

ถ้าไม่มี 4 ชั้นนี้ browser agent จะกลายเป็น “คนช่วยกดเว็บ” ที่เร็ว แต่ audit ยาก

4) ใช้กับงาน Data-Espresso อย่างไร

สำหรับ Data-Espresso ผมมองว่าฟีเจอร์แบบนี้เหมาะกับงานซ้ำที่ต้องเห็นหน้าเว็บจริง แต่ไม่ควรแตะ action เสี่ยง

ตัวอย่างที่เหมาะ:

1. เช็กหน้า landing page หลังแก้ copy หรือ CSS
2. เช็กว่า CTA และ payment link แสดงถูกใน desktop/mobile
3. เช็ก console error หลัง deploy
4. เก็บ screenshot proof ก่อนส่งให้ editor หรือ owner approve
5. เช็กว่า form validation ทำงานกับ test data
6. เช็กหน้า preview ก่อน publish จริง

ตัวอย่างที่ยังไม่ควรให้ทำเอง:

1. กดส่ง email campaign จริง
2. กดชำระเงินหรือเปลี่ยนราคา
3. เปลี่ยน DNS, redirect, canonical หรือ tracking ที่กระทบ production
4. เข้า admin ด้วย session เจ้าของโดยไม่มีขอบเขต
5. ลบข้อมูลลูกค้า, อัปเดต CRM จริง หรือเปลี่ยน setting สำคัญ

หลักคือให้ agent เข้าใกล้ “proof” มากขึ้น แต่ยังไม่ต้องเข้าใกล้ “irreversible action”

Operator Kit: Browser Agent QA Checklist

ใช้เช็กลิสต์นี้ก่อนให้ AI agent เปิด browser ทดสอบเว็บจริง

1. ระบุ environment ก่อนเสมอ: local, staging, preview หรือ production read-only
2. ระบุ allowed domains: ให้เปิดเฉพาะ domain ที่เกี่ยวกับงาน และ block domain ที่เสี่ยง
3. ใช้ test account แทน owner account ถ้า flow ต้อง login
4. ห้าม share user tab ที่มีข้อมูลส่วนตัวหรือ session สำคัญ เว้นแต่จำเป็นและมีขอบเขตชัด
5. ระบุ action ที่ทำได้: navigate, click, type test data, inspect, screenshot
6. ระบุ action ที่ห้ามทำ: publish, send, charge, delete, change pricing, change DNS, update production settings
7. ถ้าต้องใช้ permission เช่น clipboard read, location, microphone หรือ camera ให้หยุดและขอมนุษย์อนุมัติ
8. ให้ agent บันทึก step ที่ทำจริง ไม่ใช่สรุปแค่ว่า “ทดสอบแล้ว”
9. ต้องมี proof อย่างน้อย 3 อย่าง: URL, screenshot, console/log observation
10. แยก expected result กับ actual result ให้ชัด
11. ถ้าพบ error ให้รายงาน reproduction steps ก่อนเสนอ fix
12. หลังจบงาน ให้บอกสิ่งที่ไม่ได้ทดสอบ เพื่อไม่ให้ทีมเข้าใจว่าครอบคลุมทั้งหมดแล้ว

Prompt สั้น ๆ ที่เอาไปใช้ได้:

เปิด browser ทดสอบเฉพาะ URL นี้ใน environment นี้:


ขอบเขต:
- ทำได้: navigate, click, type test data, inspect console, take screenshots
- ห้ามทำ: publish, send email, payment, delete data, change settings
- ถ้าต้องใช้ permission หรือเจอหน้า login/session สำคัญ ให้หยุดถามก่อน

ส่งผลลัพธ์กลับมาเป็น:
1. steps ที่ทำ
2. expected vs actual
3. console errors
4. screenshot proof
5. สิ่งที่ยังไม่ได้ทดสอบ

6) Caveat: Browser proof ไม่ใช่ full QA

Browser agent ช่วยให้เราเห็นปัญหาเร็วขึ้น แต่ไม่แทน test strategy ทั้งหมด

มันไม่ได้แทน unit test, integration test, Playwright suite, accessibility audit, security review หรือการ approve จากคนที่ถือ business judgment

และที่สำคัญ มันยังต้องอยู่ใต้ policy ของทีม

ถ้าทีมใช้ฟีเจอร์นี้ใน VS Code ควรคุยกันก่อนว่า:

ใครเปิดใช้ได้

เปิดกับ repo ไหน

เปิดกับ domain ไหน

เปิดกับ production ได้แค่ไหน

proof format เป็นอย่างไร

และ action ไหนต้องหยุดรอมนุษย์

สรุป

GitHub Copilot Browser Tools ทำให้ AI coding agent เข้าใกล้งาน QA จริงขึ้นมาก

นี่เป็นข่าวดีสำหรับทีมเล็ก เพราะช่วยลดงานกดเว็บซ้ำ ๆ และทำให้ agent ส่งหลักฐานกลับมาได้มากกว่าแค่ข้อความ

แต่ข่าวดีนี้จะมีค่าจริงเมื่อทีมวางขอบเขตไว้ก่อน

อย่าให้ AI “ลองเปิดเว็บดู” แบบกว้าง ๆ

ให้มันทำงานแบบ operator:

มี domain ที่อนุญาต มี session ที่ปลอดภัย มี action ที่ชัด มี permission ที่ต้องถาม และมี proof ที่ตรวจซ้ำได้

AI ที่เปิด browser ได้ไม่ใช่แค่ผู้ช่วยเขียนโค้ดแล้ว

มันคือผู้ช่วยตรวจงานหน้าเว็บ

และผู้ช่วยแบบนี้ต้องมีเช็กลิสต์ก่อนเริ่มงานเสมอ