CupCode.cc
Section 05 · Module 01 · Lesson 02 · ~20–24 นาที

สิ่งที่ AI ทำได้ดี และสิ่งที่ยังต้องพึ่งคน

บทนี้พาคุณเห็นจุดแข็งและจุดอ่อนของ AI ในงาน QA แบบลงรายละเอียด เพื่อให้คุณเลือกใช้งานได้ถูกที่ ไม่หลงเชื่อมากเกินจริง และไม่ปฏิเสธโดยไม่จำเป็น

เวลาเรียน: 20–24 นาที ต้องรู้มาก่อน: Lesson 01 - AI กำลังเปลี่ยน Workflow ของ QA รูปแบบ: อ่าน + comparison table + แบบฝึก mapping

จบบทนี้แล้วคุณจะ...

  • ระบุประเภทของงาน QA ที่ AI ทำได้ดีจริง ๆ และที่ยังเปราะบาง
  • เข้าใจ failure mode หลักของ LLM ในงาน testing
  • รู้ว่าเมื่อไหร่ควร trust AI output และเมื่อไหร่ควร skeptic
  • ออกแบบ workflow ที่ใช้ทั้งคนและ AI โดยให้แต่ละฝ่ายทำในสิ่งที่ตัวเองเก่ง
1 · จุดแข็งหลักของ AI ในงาน testing

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 ที่มนุษย์ลืมเพราะคิดในกรอบเดิม

2 · จุดอ่อนหลักที่ต้องระวัง

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 กลางทาง

3 · เปรียบเทียบจุดแข็ง / จุดอ่อน เป็น matrix

ใช้เป็น 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
4 · กฎ "trust แต่ verify"

นี่คือหลักที่ทุก 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 ไหม"
5 · งานที่ห้ามให้ AI ทำเดี่ยว ๆ

มี 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" ต้องเป็นคน เพราะถ้าผิดแล้วจะมีคนรับผิด

Practice

แบบฝึก: เขียน 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 ทำได้ ทำไม่ได้ จะช่วยให้ใช้งานได้ปลอดภัย