AI แบบเอเจนต์ต้องการผู้ทดสอบเพิ่ม ไม่ใช่น้อยลง

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

ผลสำรวจนักพัฒนา Stack Overflowประจำปี 2025 พบว่า ผู้ตอบแบบสำรวจ 84% กำลังใช้หรือวางแผนจะใช้เครื่องมือ AI ในการพัฒนา และนักพัฒนาซอฟต์แวร์มืออาชีพ 51% ใช้เครื่องมือเหล่านี้ทุกวัน ความรู้สึกเชิงบวกลดลงเหลือ 60% และมีนักพัฒนาที่ไม่ไว้วางใจความแม่นยำของ AI อย่างชัดเจน (46%) มากกว่าผู้ที่ไว้วางใจ (33%) สิ่งที่สร้างความหงุดหงิดมากที่สุด ซึ่งผู้ตอบ 66% ระบุ คือคำตอบที่เกือบถูกแต่ยังไม่ถูกต้องเสียที งานวิจัย DORA ประจำปี 2025 ของ Google Cloud รายงานว่า ผู้เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์นำ AI มาใช้ในสัดส่วน 90% โดยกว่า 80% ระบุว่า AI ช่วยเพิ่มผลิตภาพ แต่มีเพียง 24% ที่รายงานว่าไว้วางใจ AI มากหรือมากเป็นพิเศษ ประโยชน์ที่ยังขาดความไว้วางใจนี่เองคือเงื่อนไขที่ทำให้งานของผู้ทดสอบขยายขึ้น ไม่ใช่ลดลง

ความเร็วไม่ใช่หลักฐานยืนยัน

ฉันทำงานเป็นวิศวกรคุณภาพซอฟต์แวร์ โดยมุ่งเน้นการทดสอบระบบแบบเอเจนต์และด่านตรวจสอบ CI สำหรับโค้ดที่ AI เขียนขึ้น ภายในองค์กร เราได้เปิดใช้งานเครื่องมือตรวจทานคำขอผสานโค้ด (PR) และเครื่องมือสร้างกรณีทดสอบ ทั้งสองอย่างเป็นเครื่องมือสำหรับร่างงาน ไม่มีเครื่องมือใดให้คะแนนงานของตัวเอง กฎข้อนี้สำคัญ เพราะเอเจนต์พูดอย่างมั่นใจ แต่ความมั่นใจไม่ได้แปลว่าถูกต้อง

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

เหตุการณ์นี้เป็นส่วนหนึ่งของรูปแบบปัญหาที่พบได้กว้างกว่า รายงาน สถานะการสร้างโค้ดด้วย AI เทียบกับมนุษย์ของ CodeRabbit วิเคราะห์คำขอผสานโค้ดแบบโอเพนซอร์สบน GitHub จำนวน 470 รายการ (สร้างร่วมกับ AI 320 รายการ และสร้างโดยมนุษย์เท่านั้น 150 รายการ) การเปลี่ยนแปลงที่ AI เขียนขึ้นก่อให้เกิดปัญหาโดยรวมมากกว่าประมาณ 1.7 เท่า โดยพบปัญหาด้านตรรกะและความถูกต้องบ่อยขึ้น 75% และพบข้อบกพร่องด้านความปลอดภัยมากขึ้นสูงสุด 2.74 เท่า รายงาน ความปลอดภัยของโค้ด GenAIประจำปี 2026 ของ Veracode ทดสอบโมเดลด้วยงานด้านความปลอดภัยหลายประเภท และพบว่าอัตราการผ่านด้านความปลอดภัยเฉลี่ยอยู่ที่ 56% แทบไม่เปลี่ยนจาก 55% ในรายงานฉบับก่อน ขณะที่งานสร้างโค้ดด้วย AI ประมาณ 44% ทำให้เกิดช่องโหว่ที่ทราบกันอยู่แล้ว การเขียนไวยากรณ์โค้ดแทบไม่ใช่ปัญหาอีกต่อไป แต่การทำให้โค้ดทำงานได้อย่างปลอดภัยและถูกต้องยังเป็นปัญหา ผู้ทดสอบคือคนที่ไม่ยอมสับสนระหว่างสองเรื่องนี้

แพ็กเกจที่ AI แต่งขึ้นเป็นปัญหาด้านการทดสอบ

การสร้างโค้ดยังทำให้เกิดแพ็กเกจที่ไม่มีอยู่จริง งานวิจัยด้านความปลอดภัยของ USENIX Security 2025 เรื่อง เรามีแพ็กเกจมาให้คุณ!ประเมินการหลอนชื่อแพ็กเกจในโมเดลภาษาขนาดใหญ่ (LLM) สำหรับสร้างโค้ด 16 โมเดล โดยใช้ตัวอย่าง 576,000 รายการ โดยเฉลี่ยแล้ว โมเดลเชิงพาณิชย์แต่งชื่อแพ็กเกจขึ้นมาอย่างน้อย 5.2% ของเวลาใช้งาน ส่วนโมเดลโอเพนซอร์สมีค่าเฉลี่ย 21.7% และสร้างชื่อหลอนที่ไม่ซ้ำกัน 205,474 ชื่อ แพ็กเกจลวงที่ยังคงปรากฏอยู่เหล่านี้เปิดช่องให้เกิดการดักจดชื่อแพ็กเกจที่ AI แต่งขึ้น ผู้โจมตีจดทะเบียนชื่อที่ถูกสร้างขึ้น แล้วรอให้นักพัฒนาหรือเอเจนต์ติดตั้งแพ็กเกจนั้น

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

ด่านตรวจสอบที่รองรับการขยายตัวของเอเจนต์

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

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

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

สิ่งเหล่านี้ไม่ได้มาแทนการทดสอบ API การทดสอบการยืนยันตัวตน การทดสอบเบื้องต้น หรือระบบทดสอบอัตโนมัติของ UI เพราะ FlaUI และ PowerShell ยังคงตรวจจับปัญหาที่ API มองไม่เห็นได้ ส่วนการจัดทำแพ็กเกจผ่าน NuGet, MSI และ MSM ก็ยังต้องตรวจสอบการติดตั้งและเส้นทางการติดตั้งแบบเงียบ เวิร์กโฟลว์แบบเอเจนต์เพิ่มปริมาณงาน แต่ไม่ได้ทำให้แนวปฏิบัติเหล่านั้นหมดความจำเป็น

ผู้ทดสอบเพิ่มขึ้น แต่งานเปลี่ยนไป

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

การจ้างและสนับสนุนคนที่มีเส้นทางอาชีพนอกกรอบแบบเดิมเป็นเรื่องสำคัญในที่นี้ ฉันเปลี่ยนมาทำงานด้านคุณภาพหลังจากทำงานด้านปฏิบัติการทรัพยากรบุคคลและข้อมูล เรียนจบปริญญาโทสาขาระบบสารสนเทศจาก UMBC ในเดือนพฤษภาคม 2024 และตอนนี้ใช้เวลาทำให้ด่านควบคุมสำหรับ AI แบบเอเจนต์นำไปใช้ได้จริง AI แบบเอเจนต์จะไม่รอให้มีคนที่มาจากเส้นทางเดียวกันเท่านั้น แต่ต้องการคนที่ออกแบบหลักฐานยืนยันได้มากขึ้น ไม่ใช่คนที่ประทับตราผ่านให้บิลด์ที่ขึ้นสถานะสีเขียวโดยไม่ตรวจสอบ

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