ให้ AI เปลี่ยนแชตแจ้งปัญหาเป็นรายงานบั๊ก แล้ว Reproduce ด้วยตัวเองก่อนส่งให้ Dev แก้

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

รายงานบั๊ก (Bug Report) ที่ Dev Reproduce (ทำตามขั้นตอนแล้วเจอปัญหาเดียวกัน) ไม่ได้ มักจบด้วยประโยคว่า "เครื่องผมใช้ได้นะ" แล้วบั๊กก็ยังอยู่ต่อไป ส่วนข้อความแจ้งปัญหาที่ QA ได้รับจริงมักไม่ใช่รายงานที่เรียบร้อย แต่เป็นแชตที่มีทั้งสิ่งที่เห็นจริงและการเดาปนกันอยู่

ตอนนี้เราให้ AI ร่างรายงานบั๊กจากแชตแบบนั้น แล้วทำสิ่งที่ AI ทำแทนไม่ได้ คือลอง Reproduce ด้วยตัวเอง

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

รายงานบั๊กมีไว้ทำอะไร

หลักสูตร ISTQB Foundation Level (ฉบับ 4.0.1) บอกว่าเป้าหมายแรกของรายงานบั๊ก (ISTQB เรียกว่า Defect Report) คือให้คนที่ต้องแก้มีข้อมูลพอที่จะแก้ได้ รายงานที่เขียนระหว่างทดสอบโดยทั่วไปมีข้อมูล เช่น

• หัวข้อสั้นๆ
• สภาพแวดล้อมที่ทดสอบ
• ขั้นตอนที่ทำให้เจอปัญหา
• ผลลัพธ์ที่คาดหวัง (Expected Result) และผลที่เกิดจริง
• ความรุนแรง (Severity)
• ลำดับความสำคัญที่ต้องแก้ (Priority)

ขั้นตอนที่ทำให้เจอปัญหาคือส่วนที่ AI เขียนให้ดูดีได้ แต่ยืนยันแทนเราไม่ได้

แชตแจ้งปัญหาที่ได้รับ (สมมติ)

แอดมินร้านส่งข้อความนี้มาในกลุ่มของทีม

น้องๆ ช่วยดูหน่อย ลูกค้าทักมาในไลน์ร้านว่าใช้โค้ด SAVE10 ได้ทั้งที่ซื้อไม่ถึง 500 สงสัยระบบคิดเงินผิด หรือโค้ดหลุดไปในกลุ่มดีลรึเปล่า 555
พี่เปิดดูออเดอร์ #1001 ยอด 365 บาท มีส่วนลด 35 บาทจริง
ลูกค้าเล่าว่าตอนแรกใส่เมล็ดกาแฟไว้ 2 ถุงแล้วใส่โค้ด แล้วค่อยเอาออกไปถุงนึง มั้งนะ ลูกค้าก็จำไม่ค่อยได้
ใช้มือถือสั่ง ระบบน่าจะช้าด้วยแหละช่วงนี้
แก้ด่วนเลยนะ เสาร์นี้จะเริ่มยิงแอดแล้ว

ข้อความนี้มีทั้งสิ่งที่เห็นจริงและการเดาปนกัน ส่วนกติกาของร้านที่เกี่ยวข้องคือ SAVE10 ลด 10% สูงสุด 100 บาท เมื่อยอดสินค้าถึง 500 บาท และค่าส่ง 50 บาท

รอบที่ 1: ให้ AI ร่างรายงาน

เราวางแชตนี้ลงใน Prompt ฟรี: เปลี่ยนคำบ่นของลูกค้าให้เป็นรายงานบั๊กที่ทีม Dev ทำตามแล้วเจอปัญหาเดียวกันได้ (ต้องสมัครสมาชิกฟรี) และบอกข้อมูลเพิ่ม 3 อย่าง คือเป็นหน้าตะกร้าและโค้ดส่วนลด ใช้นิยาม Severity ค่าเริ่มต้น และวันเสาร์จะยิงโฆษณา

สิ่งที่ Claude ทำได้ดี

• แยกการเดาออกไป "ระบบคิดเงินผิด" "โค้ดหลุด" และ "ระบบน่าจะช้า" ถูกจัดเป็นการตีความของคนแจ้ง Claude ไม่นำเข้ารายงาน และบอกว่าถ้ายืนยันได้ว่าระบบช้าจริง ค่อยเปิดรายงานแยก
• ไม่แต่งขั้นตอนเอง ขั้นตอนที่ลูกค้าเล่าถูกเขียนว่า "ยังไม่ได้ยืนยัน" ส่วนที่ไม่รู้ใส่ [ต้องถาม] ไว้ เช่น เอาของออกตอนไหน และที่หน้าไหน
• จับตัวเลขที่ไม่เข้ากัน Claude สังเกตว่า 35 บาทไม่ใช่ 10% ของ 365 หรือของ 400 แล้วถามว่ายอดนี้รวมค่าส่งหรือไม่ แทนที่จะเดาเอง
• แยก Severity กับ Priority ให้ Severity เป็น Critical แบบ "เบื้องต้น" เพราะเงินผิด และให้ Priority เป็น High เพราะวันเสาร์จะมีคนเข้าร้านมากขึ้น พร้อมบอกว่าถ้ายืนยันไม่ได้ค่อยลดระดับ
• บอกให้ QA ลอง Reproduce ก่อน โดยไม่ต้องรอลูกค้าตอบ

สิ่งที่ AI ทำไม่ได้: ขั้นตอนทั้งหมดยังเป็นคำบอกเล่าของลูกค้าที่ "จำไม่ค่อยได้" รายงานแบบนี้ส่งให้ Dev ได้ แต่ Dev อาจ Reproduce ไม่ได้

รอบที่ 2: Reproduce ด้วยตัวเองตามขั้นตอนที่ AI เขียน

เราทำตามขั้นตอนที่ AI เขียน แล้วลองเปลี่ยนทีละจุดที่ AI ใส่ [ต้องถาม] ไว้ (เมล็ดกาแฟถุงละ 350 บาท) ผลเป็นดังนี้

เมื่อจ่ายด้วยบัตรทดสอบตามทาง A ได้ออเดอร์ยอด 365 บาท ตรงกับออเดอร์ของลูกค้า ตัวเลขที่ AI สงสัยก็คลี่คลาย คือยอดสินค้า 350 บาท ลด 35 บาท (10% ของ 350) แล้วบวกค่าส่ง 50 บาท

การลองเองทำให้ได้ข้อมูล 3 อย่างที่ไม่มีในรายงานรอบแรก

1. Reproduce ได้จริงกี่ครั้งจากกี่ครั้ง รายงานเปลี่ยนจาก "ลูกค้าเล่า" เป็น "ยืนยันแล้ว 3 จาก 3 ครั้ง"
2. ทาง C ซึ่งลูกค้าไม่ได้เล่า และ AI ไม่ได้คิดถึง ถ้า Dev แก้แค่ปุ่ม − บั๊กจะยังเหลืออยู่ในทางนี้
3. ทาง D คือกรณีเทียบ แสดงว่าระบบตรวจขั้นต่ำ 500 บาทได้ถูกต้องตอนใส่โค้ด ปัญหาอยู่ที่ระบบไม่ตรวจซ้ำเมื่อตะกร้าเปลี่ยน (ข้อนี้เราสรุปจากสิ่งที่เห็นบนจอ ไม่ได้ดูโค้ด)

รอบที่ 3: ส่งผล Reproduce กลับให้ AI อัปเดตรายงาน

เราส่งตารางผล Reproduce และข้อ Requirement ที่เกี่ยวข้องกลับไปให้ Claude อัปเดตรายงาน Claude รวม 3 ทางไว้ในรายงานเดียว โดยให้เหตุผลว่าทั้ง 3 ทางให้ผลผิดแบบเดียวกัน และขัด Requirement ข้อเดียวกัน ถ้าแยกเป็นหลายใบ อาจมีการแก้ทางหนึ่งแล้วอีกทางยังผิดอยู่

ในส่วนที่ Requirement ไม่ได้บอก Claude ไม่เดา (ข้อนี้เราช่วยด้วย เพราะในคำสั่งรอบนี้เราเขียนบอกไว้ว่าเอกสารไม่ได้ระบุเรื่องการแก้ตะกร้าหลังใส่โค้ด) Expected Result ที่ Claude เขียนมีดังนี้

ผลที่คาดหวัง:
- ตาม requirement: SAVE10 ใช้ได้เมื่อยอดสินค้า (ไม่รวมค่าส่ง) ตั้งแต่ 500 บาทขึ้นไป
  ยอดสินค้า 350 บาทจึงต้องไม่ได้ส่วนลด ยอดที่ต้องจ่ายควรเป็น 350 + 50 = 400 บาท
- เมื่อแก้ตะกร้าหลังใส่โค้ดแล้ว ระบบควรทำอะไร เช่น ถอดโค้ดออกเอง ...
  เอกสารไม่ได้ระบุ [ต้องถาม PO]

ยอด 400 บาทในกล่องคือผลที่ควรได้ ถ้าระบบตรวจขั้นต่ำซ้ำตาม AC-2.4 แต่ Requirement ไม่ได้บอกว่าต้องตรวจซ้ำ Claude จึงใส่ [ต้องถาม PO] ไว้คู่กัน

แต่ยังมี [ต้องถาม] เหลืออยู่ในเรื่องที่ QA รู้อยู่แล้ว เช่น ใส่โค้ดที่หน้าไหน ล็อกอินอยู่หรือไม่ และทาง B กับ C ทำกี่ครั้ง ช่องเหล่านี้ต้องเติมเองก่อนส่ง

กติกา: Reproduce ด้วยตัวเองทุกครั้งก่อนส่งรายงาน

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

ถ้า Reproduce ไม่ได้ ก็ยังส่งรายงานได้ แต่ต้องเขียนตรงๆ ว่า "ยัง Reproduce ไม่ได้ ลองแบบนี้ไปแล้ว" ไม่ใช่ส่งขั้นตอนที่ยังไม่เคยมีใครลอง

เช็กลิสต์ตรวจรายงานบั๊กที่ AI เขียน

• Steps to Reproduce เราลองเองแล้ว และเขียนว่าเกิดกี่ครั้งจากกี่ครั้ง
• ไม่มีสาเหตุที่เดาเอง เช่น "API ช้า" ถ้าไม่มีหลักฐาน
• Expected Result อ้างจากข้อ Requirement ที่ระบุได้ ส่วนที่ Requirement ไม่ได้บอกเขียนเป็นคำถาม
• ผลจริงบอกว่าเห็นอะไรบนจอ โดยใช้ตัวเลขและข้อความตรงตัว
• มีกรณีเทียบที่ระบบทำงานถูก ถ้ามี
• ช่อง [ต้องถาม] ที่ QA ตอบเองได้ เติมครบแล้ว
• ไม่มีข้อมูลลูกค้าจริง ชื่อ เบอร์ หรือเลขบัตร ติดไปในรายงานหรือในแชตกับ AI

คำสั่งสำเร็จรูป: อัปเดตรายงานหลัง Reproduce

คำสั่งนี้ดัดแปลงจากคำสั่งที่เราใช้ในรอบที่ 3 ให้ใช้กับงานทั่วไปได้

ด้านล่างคือ bug report ร่าง และผลที่ฉันลองทำซ้ำเอง
อัปเดตรายงานให้พร้อมส่ง developer
- ใช้ผลทำซ้ำแทนคำบอกเล่า และบอกว่าเกิดกี่ครั้งจากกี่ครั้ง
- ผลที่คาดหวังให้อ้างจาก requirement ที่แนบ ส่วนที่ requirement ไม่ได้บอก ให้เขียนเป็นคำถามถึง PO
- ช่องที่ยังไม่รู้จริง ให้คงเป็น [ต้องถาม] ห้ามเติมเอง
- ห้ามเขียนสาเหตุในโค้ด เขียนแค่อาการที่เห็น
- ถ้ามีหลายทางที่ทำให้เกิด บอกว่าควรรวมหรือแยกรายงาน และเพราะอะไร

requirement ที่เกี่ยวข้อง:
"""
[วางข้อ requirement]
"""

ผลทำซ้ำ (สภาพแวดล้อม วันที่ ขั้นตอน ผลที่เห็น จำนวนครั้ง):
"""
[วางผลที่ลองเอง รวมกรณีที่ทำงานถูกด้วย]
"""

รายงานร่างเดิม:
"""
[วางรายงานร่าง]
"""

ทำไมได้ผล: การแนบ Requirement ทำให้ Expected Result มีที่มา การบอกให้ใส่จำนวนครั้งทำให้ Dev รู้ว่าบั๊กเกิดแน่นอนแค่ไหน และกรณีที่ระบบทำงานถูกช่วยให้ Dev จำกัดจุดที่ต้องดูให้แคบลง

สรุป

ให้ AI แยกสิ่งที่เห็นจริงออกจากการเดา แล้วร่างรายงาน จากนั้นลอง Reproduce เอง ทั้งทางที่ AI เขียนไว้ และทางที่ AI ใส่ [ต้องถาม] ไว้ แล้วส่งผลกลับให้ AI จัดรายงานใหม่ ก่อนส่งให้ Dev ให้ตรวจด้วยเช็กลิสต์ข้างบนอีกครั้ง

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

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