ให้ AI ช่วยคิดว่าควรลองอะไร แล้วทำ Exploratory Testing หน้าตะกร้าและหน้าชำระเงินด้วยตัวเอง

ตอนที่ 4 ของซีรีส์ "QA ใช้ AI ทำงาน"

Test Case ที่เขียนจาก Requirement ตรวจได้แค่สิ่งที่มีคนเขียนไว้ แต่ลูกค้าจริงพิมพ์ -1 ในช่องจำนวน กดปุ่มจ่ายสองครั้ง หรือรีเฟรชตอนกำลังตัดบัตร ซึ่งไม่มีใครเขียนไว้

การทดสอบแบบนี้เรียกว่า Exploratory Testing ตอนนี้เราให้ AI ช่วยคิดว่าควรลองอะไร แต่คนเป็นผู้ลองและตัดสิน

ข้อมูล ณ ตุลาคม 2569 เราทดสอบกับร้านกาแฟตัวอย่าง (ร้านสมมติ) ที่สร้างไว้ทดสอบและตั้งใจใส่บั๊กไว้ ผลทุกขั้นรันจริงเมื่อ 17 ตุลาคม 2569 ด้วย Chromium บนคอมพิวเตอร์ และเราลองกับ Claude อย่างเดียว

Exploratory Testing คืออะไร

หลักสูตร ISTQB Foundation Level (ฉบับ 4.0.1) อธิบายว่าเป็นการทดสอบที่ออกแบบ ลงมือ และประเมินผลไปพร้อมกัน ระหว่างที่ผู้ทดสอบเรียนรู้ระบบ มักทำเป็น Session ที่จำกัดเวลา ใช้ Test Charter บอกเป้าหมาย และจบด้วยการคุยสรุปผลกับทีม (Debrief)

หลักสูตรบอกด้วยว่าวิธีนี้มีประโยชน์เมื่อ Requirement ไม่ครบหรือเวลาบีบ ใช้เสริมการเขียน Test Case แบบเป็นทางการได้ และได้ผลดีกว่าเมื่อผู้ทดสอบมีประสบการณ์ รู้จักธุรกิจ และช่างสงสัย ข้อนี้คือส่วนที่ AI ทำแทนไม่ได้

Charter คือโจทย์ ไม่ใช่ขั้นตอน

Charter ที่นิยมเขียนมี 3 ส่วน ดังนี้

สำรวจ [ส่วนไหนของระบบ] ด้วย [ข้อมูล เครื่องมือ หรือวิธี] เพื่อหา [ข้อมูลหรือความเสี่ยงแบบไหน]

รูปแบบนี้มักอ้างถึงหนังสือ Explore It! ของ Elisabeth Hendrickson (2013) ซึ่ง ISTQB ใช้เป็นหนังสืออ้างอิง ในบทที่สำนักพิมพ์เปิดให้อ่าน เธอเขียนว่า Charter ที่ดีคือ "prompt" ที่ชี้ไปยังแหล่งไอเดีย โดยไม่กำหนดว่าต้องทำอะไรหรือต้องได้ผลอะไร และยกคำถามตัวอย่างว่า มีกรณีไหนที่ลูกค้าอาจโดนเก็บเงินซ้ำหรือไม่

ขั้นที่ 1: ให้ AI เสนอ Charter

เราให้ Claude ดูแค่ Requirement ของร้าน (ไม่ให้ดูโค้ด เหมือน QA ที่เห็นแค่หน้าเว็บ) แล้วขอ Charter 3 ข้อเรียงตามความเสี่ยง พร้อมไอเดีย 10 ข้อสำหรับ Charter แรก Charter ที่ได้มีดังนี้

ไอเดียของ Charter A ละเอียดมาก Claude สังเกตว่าขั้นต่ำของคูปองดูยอดก่อนหักส่วนลด แต่ส่งฟรีดูยอดหลังหักส่วนลด จึงสลับกันได้ง่าย และยังคิดตะกร้าที่ยอดคร่อมเส้นให้ด้วย เช่น 1,090 กับ 1,100 ซึ่งเราคิดเลขทวนแล้วถูกทุกตัว

ขั้นที่ 2: คนเลือกว่าจะลอง Charter ไหน

Claude จัดให้ A เสี่ยงที่สุด เราเห็นด้วย แต่ในซีรีส์นี้ ตอนที่ 2 เขียน Test Case ค่าขอบเรื่องเงินไปแล้ว รอบนี้จึงเลือก B กับ C ซึ่งเป็นเรื่องจังหวะเวลาและค่าแปลกๆ ที่ Test Case มักไม่ครอบคลุม

AI ไม่รู้ว่าทีมทดสอบอะไรไปแล้วบ้าง การเลือก Charter จึงเป็นงานของคน

ขั้นที่ 3: ลงมือลองตาม Charter B และ C

เราลองตามไอเดียใน Charter B และ C แล้วบันทึกผลด้วยสคริปต์ Playwright เพื่อให้ได้ตัวเลขตรงตัว สินค้าที่ใช้คือแก้วเซรามิก 290 บาท มีสต็อก 3 ชิ้น และดริปแบ็ก 150 บาท รอบนี้ยังไม่ได้ลองปุ่มย้อนกลับและไปข้างหน้า การเปิดหลายแท็บ การวางข้อความลงช่อง และการลองบนมือถือ ผลที่ได้มีดังนี้

ผลที่หนักที่สุดมาจากการต่อยอดไอเดียเอง Charter C บอกให้หาจำนวนที่ระบบรับทั้งที่ผิดกฎ เราเห็นว่า −1 ผ่าน จึงถามต่อว่า "แล้วจ่ายได้ไหม" แล้วใส่ดริปแบ็ก 1 ชิ้นกับแก้ว −1 ชิ้น แล้วกดจ่าย ได้ข้อความ "จ่ายสำเร็จ ออเดอร์ #1001 ยอด -90 บาท"

ส่วนออเดอร์ซ้ำ Claude ชี้ไว้แล้วใน Charter B (การกดซ้ำ) ซึ่งตรงกับคำถามตัวอย่างของ Hendrickson เรื่องการเก็บเงินซ้ำ แต่ไอเดียที่ดีจาก AI ยังต้องมีคนกดจริงถึงจะรู้ผล

ขั้นที่ 4: ให้ AI สรุป Session

เราส่งโน้ตดิบที่จดระหว่างลอง (มีเครื่องหมาย ?? กับ !!! ปนอยู่) ให้ Claude ทำเป็นรายงานสำหรับ Debrief ได้ผลดังนี้

• บั๊ก 4 ข้อ เรียงตามความเสี่ยงต่อเงิน ได้แก่ จ่ายยอดติดลบได้ ออเดอร์ซ้ำ จำนวนเกินสต็อก และจำนวน 0 แต่ละข้ออ้าง AC ที่ขัด
• คำถามถึง PO 4 ข้อ ข้อที่ด่วนคือการรีเฟรชระหว่างจ่าย ซึ่งลูกค้าไม่รู้ว่าโดนตัดเงินหรือยัง ส่วนกรณี 1.5 กลายเป็น 1 Claude จัดเป็นคำถาม ไม่ใช่บั๊ก เพราะ Requirement ไม่ได้บอก
• ทักช่องโหว่ในโน้ตของเรา เช่น ยังไม่ได้ลองกดจ่ายด้วยจำนวน 0 และ 999 และโน้ตไม่ได้จดว่าหน้าจอแสดงยอดที่จ่ายในกรณีปกติอย่างไร

Claude ไม่เติมผลที่เราไม่ได้จด และเสนอ Charter รอบหน้า 2 ข้อ ข้อหนึ่งคือสำรวจการขัดจังหวะระหว่างจ่ายเงิน ซึ่งตรงกับสิ่งที่เรายังลองไม่ครบ

แบ่งงานกับ AI: อะไรให้ AI ทำ อะไรคนต้องทำเอง

คำสั่งสำเร็จรูป 1: ให้ AI เสนอ Charter และไอเดียทดสอบ

คำสั่งนี้ย่อจากคำสั่งที่เราใช้จริงในขั้นที่ 1

ฉันจะทดสอบแบบสำรวจ (exploratory) [จำนวน] นาที กับ [ส่วนไหนของระบบ]
ฉันเห็นแค่ requirement กับหน้าจอ ไม่เห็นโค้ด
สิ่งที่ทีมทดสอบไปแล้ว: [เช่น test case ค่าขอบของส่วนลด / ยังไม่มี]

1. เสนอ charter 3 ข้อ รูปแบบ "สำรวจ [ส่วนไหน] ด้วย [อะไร] เพื่อหา [อะไร]"
   เรียงจากความเสี่ยงสูงไปต่ำ พร้อมเหตุผล 1 บรรทัด
2. charter ข้อแรก ให้ไอเดีย 10 ข้อ: จะทำอะไร · ควรสังเกตอะไร · ทำไมน่าเจอปัญหา
3. ห้ามบอกว่าผลจะเป็นยังไง เพราะคุณไม่เห็นระบบจริง

requirement:
"""
[วาง requirement]
"""

คำสั่งสำเร็จรูป 2: ให้ AI สรุป Session เป็นรายงานสำหรับ Debrief

คำสั่งนี้ย่อจากคำสั่งที่เราใช้จริงในขั้นที่ 4

ช่วยเปลี่ยนโน้ตดิบจาก exploratory session ด้านล่างเป็นรายงานสำหรับ debrief
- ใช้เฉพาะสิ่งที่อยู่ในโน้ต ห้ามเติมผลที่ไม่ได้จด ห้ามเดาสาเหตุในโค้ด
- แยก 3 กลุ่ม: บั๊ก (ขัด requirement ชัด) · คำถามถึง PO · ลองแล้วทำงานถูก
- บั๊กแต่ละข้อ: หัวข้อ · ขั้นตอนสั้น · ผลที่คาดหวัง (อ้างข้อ requirement) · ผลจริง · ความเสี่ยง
- ปิดท้ายด้วย "ยังไม่ได้ลอง" และ charter รอบหน้าไม่เกิน 2 ข้อ

requirement ที่เกี่ยวข้อง: [วาง]
โน้ตดิบ: [วาง charter + สิ่งที่ลอง + ผลที่เห็น]

ทำไมได้ผล: การบอก AI ว่าทีมทดสอบอะไรไปแล้ว ทำให้ไอเดียไม่ซ้ำ การห้ามทายผลทำให้ได้ "สิ่งที่ควรสังเกต" แทนคำตอบที่ฟังดูมั่นใจ และการห้ามเติมผลทำให้รายงานมีแต่สิ่งที่เกิดขึ้นจริง

ถ้าโน้ตมีข้อมูลลูกค้าจริงหรือข้อมูลบริษัท ให้ลบออกก่อนวาง

สรุป

ให้ AI เสนอ Charter และไอเดีย แล้วคนเลือกว่าจะลองอะไร ลงมือเอง และต่อยอดไอเดียจากสิ่งที่เห็น จากนั้นให้ AI ช่วยจัดโน้ตเป็นรายงาน บั๊กที่หนักที่สุดในรอบนี้ คือออเดอร์ยอดติดลบที่จ่ายผ่าน มาจากคำถามต่อยอดของคน

ตอนถัดไปในซีรีส์ ว่าด้วยข้อมูลทดสอบที่สมจริง แต่ไม่ใช่ข้อมูลลูกค้าจริง

อาทิตย์ละสกิล เดี๋ยวก็เก่ง