ให้ AI เปลี่ยน Requirement เป็น Test Case: ได้มา 60 ข้อ แล้วต้องตรวจอะไรก่อนนำไปใช้

ตอนที่ 2 ของซีรีส์ "QA ใช้ AI ทำงาน" ต่อจากตอนที่แล้ว ซึ่งเราสรุปว่า AI ช่วยคิดและร่างได้ แต่การรันกับของจริงยังเป็นงานของ QA

ตอนนี้เราลองงานที่ QA ทำบ่อยที่สุด คือเปลี่ยน Requirement เป็น Test Case โดยให้ AI ร่าง แล้วรันทุกข้อที่รันได้กับร้านกาแฟตัวอย่าง (ร้านสมมติ) ที่เราใส่บั๊กไว้ 5 ตัว

ข้อมูล ณ ตุลาคม 2569 เราลองกับ Claude 1 รอบ กับร้านเดียว ผลที่คุณได้จะใช้คำและจำนวนข้อต่างไป ให้ดูที่วิธีตรวจเป็นหลัก

Requirement ที่ให้ AI อ่าน

ฉบับเต็มมี 4 User Story ย่อให้เห็นภาพได้ดังนี้

• ตะกร้า: จำนวนต่อรายการต่ำสุด 1 สูงสุดไม่เกินสต็อก แก้จำนวนได้ด้วยปุ่มหรือพิมพ์ตัวเลข
• คูปอง: SAVE10 ลด 10% สูงสุด 100 บาท ขั้นต่ำ 500 บาท ส่วน FREESHIP ส่งฟรี ขั้นต่ำ 300 บาท ใช้ได้ครั้งละ 1 โค้ด
• ค่าส่ง: 50 บาท ส่งฟรีเมื่อยอดสินค้าหลังหักส่วนลดตั้งแต่ 1,000 บาท
• จ่ายเงิน: ต้องกรอกที่อยู่และข้อมูลบัตรให้ครบ เมื่อจ่ายสำเร็จแล้วระบบล้างตะกร้า และถ้ากดจ่ายซ้ำระหว่างรอผล ต้องไม่เกิดออเดอร์ซ้ำ

Requirement นี้ตั้งใจเขียนให้มีช่องโหว่แบบงานจริง เช่น ไม่ได้บอกว่าถ้าแก้ตะกร้าหลังใส่โค้ดแล้ว ต้องตรวจเงื่อนไขของโค้ดใหม่หรือไม่

วิธีสั่ง AI: Prompt ที่มีหัวใจ 3 ส่วน

เราใช้ Prompt เปลี่ยน Requirement เป็น Test Case ที่ครอบคลุม Edge Case จากคลัง Prompt (สมัครสมาชิกฟรีแล้วคัดลอกได้) โดยไม่แก้คำเลย หัวใจของ Prompt นี้มี 3 ส่วน

1. ถามก่อนเขียน ให้ลิสต์จุดที่ Requirement ไม่ชัดเป็นคำถามถึง PO ก่อนเขียน Test Case
2. บังคับให้ครอบคลุม ทั้ง Happy Path ค่าขอบ ข้อมูลผิด สิทธิ์ และกรณีระบบภายนอกล่ม โดยใช้เทคนิค Equivalence Partitioning และ Boundary Value Analysis
3. ห้ามเดา พฤติกรรมที่ Requirement ไม่ได้บอก ให้ย้ายไปเป็นคำถามแทน

ค่าขอบสำคัญกับร้านค้า เพราะเงื่อนไขเรื่องเงินเต็มไปด้วยตัวเลขขั้นต่ำ ISTQB อธิบายว่าคนเขียนโปรแกรมมักพลาดตรงขอบ เช่น เขียนขอบเลื่อนไปหนึ่งค่า วิธีทดสอบคือลองค่าที่เท่ากับขอบพอดี คู่กับค่าที่อยู่ติดกัน เช่น ยอด 500 คู่กับ 490

ผลที่ได้: คำถาม 33 ข้อ และ Test Case 60 ข้อ

Claude ตอบกลับมายาวมาก แบ่งเป็น 2 ส่วน

• คำถามถึง PO 33 ข้อ
• Test Case 60 ข้อ แบ่งเป็น Happy Path 11 ข้อ ค่าขอบ 18 ข้อ ข้อมูลผิด 8 ข้อ สถานะผู้ใช้ 4 ข้อ ระบบภายนอกล่ม 4 ข้อ ความปลอดภัย 9 ข้อ และทำรายการซ้ำ 6 ข้อ

ทุกข้อมีขั้นตอน ข้อมูลทดสอบจริง และผลลัพธ์ที่คาดหวัง (Expected Result) เป็นตัวเลข เช่น Test Case หนึ่งระบุว่ายอด 1,050 บาท ใส่ SAVE10 แล้วต้องจ่าย 1,000 บาท (ลด 100 บาทเหลือ 950 บาท ไม่ถึงเกณฑ์ส่งฟรี) Claude ยังสังเกตเองด้วยว่าราคาสินค้าทุกตัวลงท้ายด้วย 0 จึงสร้างยอด 499 ไม่ได้ ค่าข้างเคียงที่ใกล้ที่สุดคือ 490

ผลเมื่อนำไปรันกับร้านจริง

เรารันได้ 43 จาก 60 ข้อ อีก 17 ข้อต้องใช้เครื่องมือที่ร้านจำลองไม่มี เช่น ดูรายการตัดเงินในระบบหลังบ้าน ดักแก้ข้อมูลระหว่างทาง หรือปรับเวลาของเครื่องเซิร์ฟเวอร์

ผลคือ ผ่าน 34 ข้อ ไม่ผ่าน 9 ข้อ และ 9 ข้อที่ไม่ผ่านชี้ไปที่บั๊ก 4 ตัว ดังนี้

เราตรวจด้วยมือแล้ว Expected Result ใน Test Case ที่ไม่ผ่านถูกตาม Requirement ทุกข้อ แปลว่าข้อที่ไม่ผ่านเกิดจากร้านทำงานผิด ไม่ใช่ AI คิดผิด

บั๊กตัวที่ 5 พบจากคำถาม ไม่ใช่จาก Test Case

ร้านมีบั๊กอีกตัว คือเมื่อใส่ SAVE10 ตอนยอด 600 บาท แล้วลบสินค้าจนยอดเหลือ 450 บาท ร้านยังลดให้ 45 บาท ทั้งที่ยอดไม่ถึงขั้นต่ำแล้ว

AI ไม่ได้เขียน Test Case ข้อนี้ ซึ่งถูกต้องแล้ว เพราะ Requirement ไม่ได้บอกว่าต้องเกิดอะไรขึ้น แต่ AI ถามเรื่องนี้ไว้ในคำถามข้อ 12

ถ้าใช้โค้ดแล้วตะกร้าลดลงจนต่ำกว่าขั้นต่ำ (เช่น ใช้ SAVE10 ที่ยอด 600 แล้วลบ DRIP เหลือ 450) ระบบถอดโค้ดเอง, ค้างโค้ดไว้แต่ส่วนลดเป็น 0, หรือขึ้นเตือน

เรานำตัวอย่างในคำถามนี้ไปลองกับร้านทันที และเจอบั๊ก บทเรียนจากเรื่องนี้คือ อย่าข้ามส่วนคำถาม เพราะมีค่าไม่น้อยกว่าตาราง Test Case

6 ข้อที่ต้องตรวจก่อนใช้ Test Case จาก AI

เช็กลิสต์นี้ได้มาจากการรันจริงครั้งนี้ และนำไปใช้กับงานของคุณได้ทันที

1. ตรวจ Expected Result ด้วยมือ ครั้งนี้ถูกทั้งหมด แต่ ISTQB เตือนว่า AI ผิดได้ในเรื่องการคำนวณและเงื่อนไขซ้อนกัน ถ้า Test Case มี Expected Result ผิด ก็จะรายงานบั๊กผิดตาม
2. หาสิ่งที่ AI สมมติเอง Requirement ไม่ได้บอกเลขบัตรทดสอบ AI จึงใช้เลขของผู้ให้บริการรับชำระเงินรายหนึ่ง และบอกไว้ว่าใช้ไปก่อน ผลคือมี Test Case "บัตรเงินไม่พอ" ที่ผ่าน แต่ผ่านเพราะร้านไม่รู้จักเลขบัตรนั้นเลย ไม่ได้ทดสอบเรื่องเงินไม่พอจริง ถามทุกครั้งว่า Test ผ่านด้วยเหตุผลที่ถูกหรือไม่
3. แยก Test Case ที่รันไม่ได้ออกมา อย่าทิ้ง 17 ข้อที่เรารันไม่ได้มีเรื่องความปลอดภัยรวมอยู่ด้วย เช่น แก้ราคาในข้อมูลที่ส่งไปตอนจ่ายเงิน ซึ่งสำคัญมาก ให้ทำเป็นรายการ "ต้องเตรียมเครื่องมือ" แยกไว้
4. ตรวจว่าค่าขอบครบทุกเกณฑ์ ทุกตัวเลขขั้นต่ำต้องมีทั้งค่าที่เท่ากับขอบพอดีและค่าข้างเคียง ครั้งนี้มีครบทั้ง 300, 500, 1,000 และเพดานส่วนลด 100
5. Expected Result แบบ "ต้องไม่เป็น…" คือสัญญาณว่า Requirement ยังไม่ครบ เช่น พิมพ์จำนวน 21 ทั้งที่สต็อกมี 20 AI เขียนได้แค่ว่า "จำนวนต้องไม่เป็น 21" เพราะไม่มีใครบอกว่าระบบต้องทำอะไร เมื่อได้คำตอบจาก PO แล้ว ให้กลับมาแก้ Test Case ให้ชัด
6. คัดคำถามก่อนส่ง PO 33 ข้อเยอะเกินไป เราจึงลองให้ Claude เลือก 5 ข้อที่ต้องถามก่อน โดยดูว่าถ้าเดาผิดแล้วจะมีใครเสียเงินหรือไม่ Claude เลือกคำถามข้อ 12 เป็นอันดับแรก แต่ในกลุ่มที่ Claude บอกว่า "QA ตัดสินเองได้" มีเรื่องที่เป็นการตัดสินใจของธุรกิจปนมา เช่น โค้ดตัวพิมพ์เล็กใช้ได้หรือไม่ ข้อแบบนี้ต้องให้ PO ตอบ

สรุป

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

งานของ QA จึงย้ายจาก "พิมพ์ Test Case" ไปเป็นการตรวจ คัด รัน และพาคำถามไปถึงคนที่ตอบได้

ตอนถัดไป เราจะนำบั๊กตัวที่ 5 มาเขียนรายงานบั๊ก (Bug Report) ที่ Dev Reproduce (ทำตามขั้นตอนแล้วเจอปัญหาเดียวกัน) ได้ตั้งแต่ครั้งแรก

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