AI ช่วย QA ได้แค่ไหน: ลองกับร้านค้าจำลองที่มีบั๊กจริง

ตอนที่ 1 ของซีรีส์ "QA ใช้ AI ทำงาน" สำหรับคนทำงานทดสอบระบบ และทุกคนที่ต้องตรวจงานก่อนปล่อยให้ลูกค้าใช้

ตอนนี้ QA หลายคนมีคำถามว่า AI ช่วยงานเราได้จริงแค่ไหน และงานส่วนไหนที่เรายังต้องทำเอง เราไม่อยากตอบจากความรู้สึก จึงลองให้เห็นกับของจริง

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

ร้านค้าจำลองที่ใช้ทดลองตลอดซีรีส์

เราสร้างร้านขายเมล็ดกาแฟออนไลน์หน้าเดียว มีตะกร้า โค้ดส่วนลด ค่าส่ง และหน้าจ่ายเงินที่ใช้ระบบจ่ายเงินจำลอง แล้วตั้งใจใส่บั๊กไว้ 5 ตัว กติกาที่ต้องรู้สำหรับตอนนี้มีเท่านี้

• โค้ด SAVE10 ลด 10% สูงสุด 100 บาท ต้องมียอดสินค้าขั้นต่ำ 500 บาท
• โค้ด FREESHIP ส่งฟรี ต้องมียอดสินค้าขั้นต่ำ 300 บาท
• ค่าส่ง 50 บาท แต่ส่งฟรีเมื่อยอดหลังหักส่วนลดตั้งแต่ 1,000 บาท
• ราคาสินค้า เช่น เมล็ดกาแฟ 350 บาท ดริปแบ็ก 150 บาท

งาน 5 อย่างที่ ISTQB บอกว่า AI ช่วยได้

ISTQB คือองค์กรที่ออกใบรับรองนักทดสอบซอฟต์แวร์ และมีหลักสูตรเฉพาะเรื่องการใช้ Generative AI ในงานทดสอบ (CT-GenAI ฉบับ 1.1 เมษายน 2569) หลักสูตรนี้ระบุงานที่ AI ช่วยได้ไว้ 5 อย่าง เราจับคู่แต่ละงานกับตอนในซีรีส์ที่จะลองให้ดู

สังเกตว่าทุกข้อเขียนว่า "ช่วย" ไม่มีข้อไหนบอกว่าทำแทนจนจบ ต่อไปมาดูว่าในงานจริง คำว่า "ช่วย" หมายถึงอะไร

ทดลอง 1: ให้ AI คิดยอดที่ควรได้

เราวาง Requirement ของร้านให้ Claude แล้วถามยอดที่ควรได้ 5 กรณี พร้อมสั่งว่า ถ้า Requirement ไม่ได้บอก ให้บอกตรงๆ แทนการเดา จากนั้นนำกรณีเดียวกันไปกดในร้านจริง ผลเทียบกันได้ดังนี้

เราตรวจด้วยมือแล้ว ตัวเลขของ Claude ถูกทั้ง 4 กรณีที่ Requirement ให้คำตอบได้ เช่น กรณีแรก ลด 100 บาทเหลือ 950 บาท ยังไม่ถึง 1,000 บาท จึงต้องเสียค่าส่ง 50 บาท รวมเป็น 1,000 บาท ส่วนกรณีสุดท้าย Claude ไม่เดา แต่บอกว่า Requirement ไม่ได้เขียนว่าต้องตรวจเงื่อนไขของโค้ดใหม่หลังแก้ตะกร้า แล้วเสนอคำถามให้นำไปถาม PO

แต่เมื่อรันกับร้านจริง ร้านคิดเงินผิด 3 ใน 4 กรณี เพราะร้านคิดส่งฟรีจากยอดก่อนหักส่วนลด และไม่รับยอดที่เท่ากับขั้นต่ำพอดี AI รู้เรื่องเหล่านี้ไม่ได้เลยจากการอ่าน Requirement เพราะมันรู้แค่ว่ายอด ควร เป็นเท่าไร แต่ไม่รู้ว่าร้านคิดจริงเท่าไร

ทดลอง 2: ถามตรงๆ ว่าร้านมีบั๊กอะไร

คราวนี้เราให้ Claude แค่ Requirement แล้วถามสั้นๆ ว่า "ร้านนี้มีบั๊กอะไรบ้าง"

Claude เปิดคำตอบด้วยประโยคนี้

ผมไม่ได้เห็นตัวแอปหรือโค้ดของร้านนี้ ได้มาแค่ requirement จึงยังบอกไม่ได้ว่าร้านนี้มีบั๊กอะไรจริงๆ

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

ครั้งนี้ Claude ตอบตรงไปตรงมา แต่ ISTQB เตือนว่าผลของ AI ไม่แน่นอน ปัญหาที่ดูเหมือนแก้แล้วในแชตหนึ่ง กลับมาเกิดอีกได้ในแชตใหม่ ถ้าวันไหน AI บอกว่า "เจอบั๊กแล้ว" ทั้งที่ไม่เคยเห็นระบบ ให้ถือว่าเป็นการเดา

ทดลอง 3: ให้ AI อ่านโค้ดของร้าน

ถ้าให้โค้ดไปด้วย AI จะทำได้มากขึ้น เราส่งไฟล์ส่วนคิดเงินของร้านให้ Claude หาจุดที่ไม่ตรงกับ Requirement

Claude เจอ 3 จุด พร้อมตัวอย่างตะกร้าและยอดที่ควรได้ ดังนี้

1. ขั้นต่ำไม่นับยอดที่เท่ากับขั้นต่ำพอดี
2. ส่งฟรีดูยอดก่อนหักส่วนลด
3. โค้ดส่วนลดไม่ถูกตรวจใหม่หลังแก้ตะกร้า

2 จุดแรกขัดกับ Requirement ตรงๆ ส่วนจุดที่ 3 Claude เขียนเองว่า "น่าจะผิด" เพราะ Requirement ไม่ได้บอกว่าต้องตรวจใหม่

เราลองกดตามตัวอย่างเหล่านั้นในร้าน ได้ยอดตรงกับที่ Claude บอกว่าโค้ดจะคิด ยกเว้นตัวอย่างเดียว คือ FREESHIP ที่ยอด 300 พอดี ซึ่งเกิดในร้านนี้ไม่ได้ เพราะบั๊กเรื่องขั้นต่ำบังไว้ก่อน

แต่ร้านมีบั๊ก 5 ตัว อีก 2 ตัวอยู่ในโค้ดส่วนหน้าจอที่เราไม่ได้ส่งไป Claude บอกเองด้วยว่า "ยังไม่ได้รันโค้ดจริง" และส่วนที่ไม่ได้ส่งมา "ตรวจไม่ได้" สรุปได้ว่า AI ตรวจได้เฉพาะสิ่งที่เราให้มันเห็น

งาน 5 อย่างที่ QA ยังต้องทำเอง

จากการทดลองและสิ่งที่ ISTQB เตือนไว้ มีงาน 5 อย่างที่ยังเป็นของเรา

1. รันกับระบบจริง ISTQB แนะนำให้ตรวจผลของ AI ด้วยการนำ Test Case ที่ได้ไปรันกับระบบจริง ทดลอง 1 คือตัวอย่างที่ชัดที่สุด ตัวเลขของ AI ถูกทุกข้อ แต่บั๊กปรากฏตอนรันเท่านั้น
2. ตัดสินว่า Requirement หมายถึงอะไร AI ตั้งคำถามได้ดี แต่คนตอบต้องเป็น PO หรือเจ้าของงาน หน้าที่ของเราคือพาคำถามไปถึงคนที่ตอบได้
3. ตรวจตัวเลขและเงื่อนไข ISTQB บอกว่า AI ผิดได้ในเรื่องที่ต้องใช้ตรรกะ เช่น เงื่อนไขซ้อนกันและการคำนวณ ครั้งนี้ Claude คิดถูก แต่เราก็ตรวจทุกตัวก่อนนำไปใช้เป็น Expected Result
4. เลือกว่าอะไรสำคัญ ISTQB ยกตัวอย่างการจัดลำดับ Test Case ว่าเป็นงานที่ AI พลาดได้ คนที่รู้ว่าลูกค้าจ่ายเงินตรงไหนบ่อย และอะไรเสียหายแรงที่สุด คือเรา
5. ดูแลข้อมูล อย่าวางข้อมูลลูกค้าจริง ข้อมูลบัตร หรือความลับของบริษัทลงใน AI เพราะ ISTQB เตือนว่าเครื่องมือ AI อาจเก็บและประมวลผลข้อมูลโดยที่เราควบคุมไม่ได้

คำสั่งสำเร็จรูป: ให้ AI คิด Expected Result โดยไม่เดา

คำสั่งนี้ดัดแปลงจากคำสั่งที่เราใช้ในทดลอง 1 ให้ใช้กับงานทั่วไปได้ และเพิ่มบรรทัดให้ AI แสดงวิธีคิด

นี่คือ requirement ของ [ระบบ / ฟีเจอร์]

"""
[วาง requirement หรือ acceptance criteria]
"""

ช่วยบอกผลที่คาดหวังของกรณีเหล่านี้
ทุกกรณีให้บอก [สิ่งที่ต้องดู เช่น ยอดสินค้า ส่วนลด ค่าส่ง ยอดที่ต้องจ่าย]

1. [กรณีที่ 1]
2. [กรณีที่ 2]

แสดงวิธีคิดของแต่ละกรณี และบอกว่าใช้ข้อไหนใน requirement
ถ้ากรณีไหน requirement ไม่ได้บอกพอที่จะตอบ ให้บอกตรงๆ ว่าไม่ได้บอก แทนการเดา

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

เมื่อได้ผลแล้ว อย่าลืม นำไปรันกับระบบจริง เพราะผลของ AI เป็นเพียงคำตอบว่ายอด "ควรเป็น" เท่าไร

สรุป

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

ตอนถัดไป เราจะให้ AI เปลี่ยน Requirement ของร้านนี้เป็น Test Case แล้วรันทุกข้อที่รันได้ เพื่อดูว่าเจอบั๊กครบหรือไม่ และต้องตัดอะไรทิ้งบ้าง

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