โค้ดผ่านการทดสอบแล้ว เรายังต้องตรวจอะไรอีก

AI รายงานว่าทดสอบผ่านทุกข้อ ในโครงการอนุมัติใบสั่งซื้อสมมติ ยอด 50,000 บาทเข้าสายผู้จัดการ ส่วน 50,000.01 บาทเข้าสายผู้อำนวยการฝ่ายจัดซื้อ การคำนวณดูถูกต้องแล้ว เรารับงานได้หรือยัง?

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

งานที่ AI ช่วยทำจึงต้องมีการตัดสินใจตรวจรับ ไม่ใช่เพียงข้อความว่าเสร็จแล้ว ในบทความนี้ นโยบายสมมติ P1 ยังใช้ยอดสุทธิเป็นบาทหลังส่วนลดและภาษี ยอดไม่เกิน 50,000 บาทให้ผู้จัดการอนุมัติ ยอดเกินกว่านั้นให้ผู้อำนวยการอนุมัติ และการแก้ยอดทำให้การอนุมัติเดิมหมดผล กติกานี้แต่งขึ้นเพื่ออธิบาย ไม่ใช่ค่าเริ่มต้นของ Odoo

เขียนเกณฑ์ตรวจรับก่อนให้ AI แก้โค้ด

คำว่า “อนุมัติได้ถูกต้อง” ยังตีความได้กว้าง ข้อความที่ทดสอบได้ควรระบุสถานะเริ่มต้น การกระทำ และผลที่คาด เช่น เมื่อใบสั่งซื้อรออนุมัติมียอด 50,000 บาทพอดี และผู้จัดการฝ่ายมีสิทธิ์ การอนุมัติต้องบันทึกคำตัดสินของผู้จัดการคนนั้น ส่วนคำขอแบบเดียวกันจากคนไม่มีสิทธิ์ต้องถูกปฏิเสธโดยไม่เปลี่ยนใบสั่งซื้อ

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

ตรวจผลของซอฟต์แวร์และพฤติกรรมของ AI

การทดสอบเปรียบเทียบผลที่พบกับผลที่กำหนดไว้ การคำนวณยอด การปฏิเสธคนไม่มีสิทธิ์ หรือการเปลี่ยนสถานะมักตรวจตรงได้ ส่วนการประเมินหรือ evals ใช้ดูพฤติกรรมที่กว้างขึ้นของ AI เช่น รู้ว่ากติกายังตอบไม่ได้และรายงานคำถามนั้นชัดเจนหรือไม่

ความต่างอยู่ที่เรื่องที่ต้องการตรวจ ไม่ใช่การแบ่งตายตัวระหว่างโค้ดกับวิจารณญาณ พฤติกรรม AI บางอย่างตรวจอัตโนมัติได้ เช่น การเรียกเครื่องมือที่ห้าม บางอย่างต้องมีเกณฑ์ให้คะแนนและคนอ่านหลักฐาน โมเดลที่ช่วยตัดสินอาจช่วยงานได้ แต่การที่มันเห็นด้วยยังไม่ใช่หลักประกันอิสระว่าโค้ดถูกต้อง

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

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

กำหนดว่าผลประเมินที่ดีหมายถึงอะไร

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

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

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

ส่งหลักฐานไปกับวงจรพัฒนา

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

ภาพต้นฉบับภาษาอังกฤษ — กดพับหรือเปิดภาพ

เปิดภาพต้นฉบับขนาดเต็ม (ภาษาอังกฤษ)

ชุดส่งต่องานนี้ควรมีนโยบาย P1 รายการเปลี่ยนแปลง ผลทดสอบและประเมิน สภาพแวดล้อมที่ใช้ เรื่องที่ยังไม่ครอบคลุม และความเห็นเรื่องการนำขึ้นใช้จากผู้ตรวจที่รับผิดชอบ หากทดสอบระบบที่พึ่งพาไม่ได้ต้องบอกให้ชัด “การตรวจที่รันได้ผ่านทั้งหมด” กับ “ตรวจการเชื่อมต่อปลายทางแล้ว” เป็นคนละข้อสรุป

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

ผมจะรับงานตามขอบเขตที่หลักฐานรองรับ หากตรวจการคำนวณแล้วแต่ยังไม่ตรวจการเชื่อมจัดซื้อจริง คำตัดสินอาจเป็น “พร้อมทดสอบแยกส่วนขั้นถัดไป” โดยไม่ต้องฝืนเลือกเพียงว่าเสร็จแล้วหรือล้มเหลว

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

ที่มาและขอบเขต

บทความนี้ต่อยอดแนวคิดการทดสอบ การประเมิน การนำผลกลับมาแก้ และ SDLC จาก The New SDLC With Vibe Coding ของ Addy Osmani, Shubham Saboo และ Sokratis Kartakis ฉบับเดือนพฤษภาคม 2569 จำนวนเงิน นโยบาย P1 กรณีประเมิน เกณฑ์ให้คะแนน และการตรวจระหว่างทดลองใช้เป็นข้อเสนอสมมติที่เขียนขึ้นใหม่ ไม่ใช่การรับรองความปลอดภัย มาตรฐานทดสอบครบชุด หรือหลักฐานผลลัพธ์จากระบบที่นำขึ้นใช้แล้ว

อ่านมุมมองเรื่องการพัฒนาด้วย AI อย่างมีแบบแผนเพิ่มเติมได้จาก Agentic Engineering ของ Addy Osmani ส่วนแนวทางตรวจรับในบทความนี้เป็นข้อเสนอที่ผมนำมาประยุกต์ ไม่ใช่รายการตรวจที่คัดมาจากบทความนั้น