ให้ AI ช่วยทำข้อมูลทดสอบที่สมจริง โดยไม่เผลอใช้ข้อมูลของคนจริง

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

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

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

ข้อมูล ณ ตุลาคม 2569 เราลองกับ Claude โดยรันแต่ละคำสั่ง 1 รอบ และกรอกข้อมูลในร้านกาแฟตัวอย่าง (ร้านสมมติ) ที่เราสร้างไว้ทดสอบ เรื่องกฎหมายในบทความนี้ไม่ใช่คำแนะนำทางกฎหมาย งานจริงให้ถามฝ่ายกฎหมายหรือ DPO ของบริษัท

ทำไมไม่ควรนำข้อมูลลูกค้าจริงไปให้ AI

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) นิยามข้อมูลส่วนบุคคลว่าเป็นข้อมูลเกี่ยวกับบุคคลที่ทำให้ระบุตัวคนนั้นได้ ไม่ว่าทางตรงหรือทางอ้อม (มาตรา 6) กฎหมายยังกำหนดให้ใช้ข้อมูลตามวัตถุประสงค์ที่แจ้งเจ้าของข้อมูลไว้ (มาตรา 21) และให้ผู้ควบคุมข้อมูลมีมาตรการรักษาความปลอดภัย เพื่อป้องกันการเข้าถึง ใช้ หรือเปิดเผยข้อมูลโดยไม่มีสิทธิ์ (มาตรา 37)

ลูกค้าให้ที่อยู่และเบอร์มาเพื่อให้ร้านส่งของ ไม่ได้ให้มาเพื่อเป็นข้อมูลทดสอบ กฎหมายไม่ได้เขียนห้ามเรื่องนี้ตรงๆ แต่การนำไปใช้นอกวัตถุประสงค์ที่แจ้งลูกค้าไว้มีความเสี่ยง และไม่จำเป็นเลยสำหรับการทดสอบ ฝั่ง ISTQB ก็เตือนไว้ในหลักสูตรการใช้ Generative AI ในงานทดสอบว่า เครื่องมือ AI อาจเก็บและประมวลผลข้อมูลโดยที่เราควบคุมไม่ได้

คำว่า "ทางอ้อม" สำคัญ เพราะการคัดลอกออเดอร์จริงมาแล้วเปลี่ยนแค่ชื่อยังไม่พอ ที่อยู่และเบอร์ที่เหลืออยู่ก็ชี้กลับไปหาคนนั้นได้

ทดลอง 1: ขอข้อมูลด้วยคำสั่งสั้นๆ

เราพิมพ์คำขอแบบที่หลายคนพิมพ์จริง

ขอข้อมูลลูกค้าตัวอย่าง 5 คน สำหรับทดสอบระบบร้านค้าออนไลน์
มีชื่อ-นามสกุล เบอร์มือถือ อีเมล ที่อยู่ รหัสไปรษณีย์ และเลขบัตรประชาชน ขอเป็นตาราง

Claude ให้ตารางมา 5 แถว และมีเรื่องที่ทำได้ดี คืออีเมลทุกอันใช้ example.com ซึ่งเป็นโดเมนที่สงวนไว้สำหรับใช้เป็นตัวอย่าง (RFC 2606) จึงส่งอีเมลออกไปหาใครไม่ได้ และ Claude เตือนเองว่าเบอร์มือถืออาจมีคนใช้อยู่จริง

แต่เมื่อดูรายละเอียดแล้ว มีเรื่องที่ต้องระวัง

• เบอร์มือถือ ขึ้นต้นด้วย 08, 06 และ 09 แบบเบอร์จริงทุกเบอร์
• ที่อยู่ เป็นถนนและตำบลที่มีอยู่จริง เปลี่ยนแค่บ้านเลขที่
• เลขบัตรประชาชน Claude บอกว่าตั้งให้ผ่านสูตรตรวจหลักสุดท้าย เราตรวจด้วยสูตรเดียวกันแล้ว ผ่านทั้ง 5 เลข

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

(ในไฟล์บันทึกผลของเรา เบอร์ เลขบัตร และบ้านเลขที่ถูกปิดไว้ก่อนเก็บ ด้วยเหตุผลเดียวกัน)

ทดลอง 2: ขอข้อมูลด้วยคำสั่งที่มีกติกา

คราวนี้เราให้ Requirement ของหน้าชำระเงินไปด้วย และใส่กติกา 4 ข้อ ดังนี้

1. ข้อมูลต้องเป็นของสมมติ
2. เลขบัตรใช้แค่เลขบัตรทดสอบ
3. แต่ละแถวที่ไม่ผ่านทดสอบเรื่องเดียว
4. กรณีไหน Requirement ไม่ได้บอก ให้เขียนว่า "requirement ไม่ได้บอก" แทนการเดา

ได้ข้อมูล 15 แถว แบ่งเป็นควรผ่าน 5 แถว ไม่ผ่าน 7 แถว และ "requirement ไม่ได้บอก" 3 แถว สิ่งที่ต่างจากทดลอง 1 มีดังนี้ (สองคำสั่งต่างกันหลายอย่างพร้อมกัน ทั้งให้ Requirement ไปด้วย กำหนดรูปแบบ และเพิ่มกติกา อีกทั้งรันอย่างละรอบ จึงบอกไม่ได้ว่าข้อไหนทำให้ได้ผล)

• ชื่อดูออกทันทีว่าปลอม ใช้ชื่อเมนูกาแฟต่อด้วยคำว่า "ทดสอบ" เช่น "ลาเต้ ทดสอบ"
• ที่อยู่เป็นของสมมติทั้งหมด เช่น "1/1 ถ.ทดสอบ แขวงสมมติ เขตตัวอย่าง"
• แต่ละแถวที่ไม่ผ่าน เปลี่ยนจากแถวตั้งต้นแค่ช่องเดียว เช่น เบอร์ 9 หลัก รหัสไปรษณีย์ 4 หลัก หรือ CVV 2 หลัก ถ้าแถวไหนพัง จะรู้ทันทีว่าพังเพราะช่องไหน
• มีแถวที่คนมักลืม เช่น CVV 000 ที่ระบบต้องไม่ตัดเลข 0 ข้างหน้าทิ้ง
• คำถามถึง PO 8 ข้อ เช่น เบอร์ที่มีขีดรับหรือไม่ บัตรหมดอายุต้องถูกปฏิเสธหรือไม่ และรหัสไปรษณีย์ต้องมีอยู่จริงหรือไม่

สำหรับเบอร์มือถือ Claude ใช้เบอร์ที่ขึ้นต้นด้วย 01 และให้เหตุผลเองว่าไม่ซ้ำกับเบอร์มือถือที่ใช้กันตอนนี้ เหตุผลนี้เรายังไม่ได้ตรวจกับแหล่งทางการ กติกาที่เราใช้จึงเป็น ห้ามโทรหรือส่ง SMS หาเบอร์ในชุดข้อมูลทดสอบเลย

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

เรากรอกข้อมูลทั้ง 15 แถวในหน้าชำระเงินของร้าน แล้วดูว่าร้านตอบอะไร ผลเป็นดังนี้

12 แถวที่ AI ติดป้ายว่าผ่านหรือไม่ผ่าน ร้านทำงานตรงกับป้ายทั้ง 12 แถว เพราะ Requirement ในส่วนนี้ชัด ส่วนที่มีประโยชน์จริงคือ 3 แถวที่ AI ไม่ยอมเดา โดยเฉพาะ บัตรหมดอายุที่จ่ายผ่าน Requirement บอกแค่ว่าต้องกรอกวันหมดอายุ แต่ไม่ได้บอกว่าใครต้องตรวจว่าบัตรหมดอายุหรือยัง ฟอร์มของร้านตรวจแค่รูปแบบ และระบบจ่ายเงินจำลองไม่ได้ดูวันที่เลย

เราลองต่ออีก 6 กรณีจากคำถามถึง PO ของ Claude พบว่ารหัสไปรษณีย์ 00000 ก็จ่ายผ่าน ส่วนชื่อที่มีแต่ช่องว่าง เบอร์ที่มีเว้นวรรค และเบอร์แบบ +66 ระบบไม่รับ

ทั้งหมดนี้ยังไม่ใช่บั๊กจนกว่า PO จะตอบ แต่เป็นคำถามที่ต้องถามก่อนปล่อยระบบ

กติกาข้อมูลทดสอบ 8 ข้อ

1. ไม่ใช้ข้อมูลลูกค้าจริง แม้แก้ชื่อแล้วก็ตาม เพราะที่อยู่และเบอร์ยังชี้ตัวคนได้
2. ตั้งชื่อให้ดูออกว่าปลอม เช่น ต่อท้ายด้วย "ทดสอบ" ใครเปิดเจอในระบบจะได้ไม่สับสน
3. อีเมลใช้ example.com ซึ่งเป็นโดเมนที่สงวนไว้ใช้เป็นตัวอย่าง
4. ห้ามโทรหรือส่ง SMS หาเบอร์ในชุดข้อมูล ถ้าต้องทดสอบการส่งจริง ให้ใช้ซิมของทีม
5. ไม่ขอข้อมูลที่ระบบไม่ได้ใช้ โดยเฉพาะเลขบัตรประชาชน ถ้าระบบต้องใช้จริง ให้ถามทีมว่ามีชุดเลขทดสอบที่ตกลงกันไว้หรือไม่
6. บัตรใช้แค่เลขบัตรทดสอบ ของระบบ หรือของผู้ให้บริการจ่ายเงินที่ใช้อยู่
7. แถวที่ไม่ผ่าน ให้เปลี่ยนทีละช่อง จะได้รู้ว่าพังเพราะอะไร
8. ติดป้ายทุกแถว ว่าผ่าน ไม่ผ่าน หรือ "requirement ไม่ได้บอก" พร้อมระบุข้อ Requirement ที่ใช้ตัดสิน

ข้อ 5 คือเรื่องที่ทดลอง 1 พลาด ส่วนข้อ 8 คือที่มาของการเจอบั๊กบัตรหมดอายุ

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

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

ฉันเป็น QA กำลังเตรียมข้อมูลทดสอบ [หน้า / ฟอร์มที่จะทดสอบ]

## requirement
[วาง requirement ของช่องที่ต้องกรอก รวมเลขบัตรทดสอบถ้ามี]

## สิ่งที่ต้องการ
ทำชุดข้อมูลทดสอบสำหรับฟอร์มนี้ [จำนวน] แถว เป็นตาราง
คอลัมน์: ID | [ช่องในฟอร์มทีละช่อง] | ควรผ่านหรือไม่ผ่าน | ข้อ requirement ที่ใช้ตัดสิน | ทดสอบอะไร

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

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

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

สรุป

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

สิ่งที่เจอจากทั้งซีรีส์ เรารวมไว้เป็นเช็กลิสต์ทดสอบร้านออนไลน์และหน้าชำระเงิน 41 ข้อ (ไฟล์ Excel) ดาวน์โหลดได้ที่หน้าเทมเพลต โดยต้องสมัครสมาชิกฟรีก่อนดาวน์โหลด

ตอนถัดไป เราจะดู Automated Test ที่ AI เขียน ซึ่งรันผ่านหมด แต่ไม่ได้ตรวจอะไรจริงเลย

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