สิ่งที่ AI ทำได้ดี และสิ่งที่ยังต้องพึ่งคน
บทนี้พาคุณเห็นจุดแข็งและจุดอ่อนของ AI ในงาน QA แบบลงรายละเอียด เพื่อให้คุณเลือกใช้งานได้ถูกที่ ไม่หลงเชื่อมากเกินจริง และไม่ปฏิเสธโดยไม่จำเป็น
จบบทนี้แล้วคุณจะ...
- ระบุประเภทของงาน QA ที่ AI ทำได้ดีจริง ๆ และที่ยังเปราะบาง
- เข้าใจ failure mode หลักของ LLM ในงาน testing
- รู้ว่าเมื่อไหร่ควร trust AI output และเมื่อไหร่ควร skeptic
- ออกแบบ workflow ที่ใช้ทั้งคนและ AI โดยให้แต่ละฝ่ายทำในสิ่งที่ตัวเองเก่ง
AI เก่งในจุดที่ "เคยใช้เวลา" ของ QA มาก ๆ
Pattern matching จาก context: ถ้ามี requirement หรือ code ให้ AI ดู มันจะร่าง test case หรือ script ที่อยู่ใน pattern เดิมของทีมได้เร็วมาก
Generation ที่มีโครงสร้าง: gen test case ตาม template, gen test data ตาม schema, gen Playwright test ตาม Page Object pattern — งานพวกนี้ AI ทำได้ดี
Summarization: สรุป failure log ยาว ๆ, สรุป diff ของ PR, สรุปสิ่งที่ทีมคุยกันใน thread — งานสรุปถนัดของ LLM โดยตรง
Translation ระหว่างรูปแบบ: แปลง manual steps เป็น Playwright code, แปลง user story เป็น Gherkin, แปลง bug report เป็น test case — งานแปลงรูปแบบที่มี mapping ชัดเจน AI เก่ง
Brainstorm edge cases: ขอให้ AI ลิสต์ edge case ของ input ใดอันหนึ่ง มักได้ idea ที่มนุษย์ลืมเพราะคิดในกรอบเดิม
AI ยังพังในจุดที่ "ต้องเข้าใจจริง" ไม่ใช่แค่ "เคยเห็น pattern"
Hallucination: AI ตอบสิ่งที่ฟังดูถูกแต่ผิด เช่น เรียก API ที่ไม่มีจริง, ใช้ method ที่ไม่มีใน library, อ้าง spec ที่ไม่มีใน requirement
Plausible-but-shallow: gen test case ที่ดูครบ แต่ไม่ assert สิ่งที่สำคัญจริง เช่น เช็ก URL แต่ไม่เช็ก content, เช็ก element มีอยู่แต่ไม่เช็กค่าใน element
ขาด business context: AI ไม่รู้ว่าระบบนี้มี user real ใช้งานอะไร, business rule ที่ไม่ได้เขียนใน spec, decision เก่าที่ทีมเคยตกลง
ตัดสินใจไม่เป็น: AI gen idea ได้แต่บอกไม่ได้ว่า "อันไหนควรทำก่อน" หรือ "อันไหน acceptable risk"
Stateful workflow ยาว ๆ: AI ในการทดสอบอัตโนมัติแบบ end-to-end หลาย session บ่อยครั้งหลุด context กลางทาง
ใช้เป็น checklist ก่อนตัดสินใจให้ AI ทำงาน
| ประเภทงาน | AI เก่ง | AI พัง |
|---|---|---|
| Gen test case จาก spec ครบ | ✓ | — |
| Gen test case จาก spec กำกวม | — | hallucinate รายละเอียด |
| Review test case ที่มีอยู่ | ✓ | บางครั้ง miss edge case |
| Decide priority ของ defect | — | ไม่มี business context |
| Convert manual steps → script | ✓ | — |
| Debug flaky test | บางส่วน | ขาด environment context |
| Gen test data realistic | ✓ | — |
| ตัดสินใจ release decision | — | accountability ไม่ได้ |
| Maintain locator ที่พัง | ✓ | บางครั้งเลือก locator เปราะ |
| สอนน้องใหม่ในทีม | บางส่วน | ขาด empathy + history |
นี่คือหลักที่ทุก QA ที่ใช้ AI ควรยึด
ใช้ AI = ยังต้องรับผิดชอบ output เหมือนเขียนเอง
หลัก verify ที่ใช้ได้กับทุก output:
- Run จริงในสภาพแวดล้อมจริง อย่าเชื่อแค่ output ที่ AI โชว์
- เช็ก reference: ถ้า AI อ้างชื่อ method, function, API — verify ว่ามีจริง
- ลองแก้ assumption: ถ้า test ผ่านทุกครั้ง ลอง break โค้ดดูว่า test fail จริงหรือเปล่า
- ดู edge case ที่ AI ไม่ได้พูดถึง — บ่อยครั้งจุดที่หายคือจุดสำคัญ
- ถามตัวเองว่า "ถ้าจุนเนียร์ในทีมเขียน output แบบนี้มา ฉันจะ approve ไหม"
มี boundary ที่ชัดเจน
- ตัดสินใจว่า bug ระดับไหน block release
- เลือก scope ของ regression run ก่อน production deploy
- คุยกับ stakeholder เพื่อ clarify requirement
- รับผิดชอบ test plan ที่ลง sign-off
- ประเมิน security risk ที่กระทบ data จริง
งานเหล่านี้ AI สามารถ assist ได้ (เช่น draft email, suggest scope) แต่ "decision" ต้องเป็นคน เพราะถ้าผิดแล้วจะมีคนรับผิด
แบบฝึก: เขียน rule ของทีมคุณ
จินตนาการว่าคุณต้องเขียน "AI Usage Guideline" ให้ทีม QA ของคุณ ลิสต์อย่างน้อย:
- 3 task ที่อนุญาตให้ใช้ AI ช่วยทำ
- 3 task ที่ใช้ AI ช่วยได้แต่ต้อง review เข้ม
- 3 task ที่ห้ามให้ AI ทำเดี่ยว
ดูตัวอย่างคำตอบ
อนุญาต:
- gen test case draft จาก user story
- gen test data fake สำหรับ dev environment
- สรุป failure log ของ test run ใน CI
Review เข้ม:
- gen Playwright script จาก manual steps (ต้อง run จริง verify)
- review PR diff (ต้อง spot check) (ต้องมีคน confirm)
- gen edge case (อาจ miss business rule)
ห้าม:
- ตัดสินใจ release / no-release
- ลบ test case ที่ "ดูซ้ำ" โดย AI judge เอง
- เขียน security test สำหรับ production data
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- AI เก่งงานที่มี structure และ pattern ชัด พังงานที่ต้องเข้าใจ business context
- Hallucination และ plausible-but-shallow คือ failure mode ที่พบบ่อยสุด
- ทุก output ของ AI ต้อง verify เสมอ — trust แต่ verify
- งาน decision และ accountability ต้องเป็นคน ห้ามมอบให้ AI
- เขียน rule ของทีมว่าอะไร AI ทำได้ ทำไม่ได้ จะช่วยให้ใช้งานได้ปลอดภัย